Walaupun teknologi tanpa pelayan telah semakin popular sejak beberapa tahun kebelakangan ini, teknologi tersebut masih dikelilingi oleh banyak salah tanggapan dan kebimbangan. Kunci masuk vendor, perkakas, pengurusan kos, permulaan dingin, pemantauan dan kitaran hayat pembangunan semuanya menjadi topik yang hangat diperkatakan apabila ia berkaitan dengan teknologi tanpa pelayan. Dalam artikel ini, kami akan meneroka beberapa topik ini, serta berkongsi petua dan pautan ke sumber yang berguna untuk membantu pemula membina aplikasi tanpa pelayan yang berkuasa, fleksibel dan kos efektif.
Salah tanggapan tentang teknologi tanpa pelayan
Ramai orang percaya bahawa pemprosesan data tanpa pelayan dan tanpa pelayan (FaaS (atau FaaS) pada asasnya adalah perkara yang sama. Oleh itu, perbezaannya tidak terlalu besar, dan ia berbaloi untuk melaksanakan ciri baharu. Walaupun AWS Lambda adalah salah satu bintang revolusi tanpa pelayan dan salah satu elemen seni bina tanpa pelayan yang paling popular, seni bina ini lebih daripada FaaS.
Prinsip teras teknologi tanpa pelayan ialah anda tidak perlu risau tentang mengurus dan menskalakan infrastruktur; anda hanya membayar untuk apa yang anda gunakan. Banyak perkhidmatan memenuhi kriteria ini, termasuk AWS DynamoDB, S3, SNS atau SQS, Graphcool, Auth0, Now, Netlify, Firebase dan banyak lagi. Ringkasnya, tanpa pelayan bermaksud memanfaatkan keupayaan penuh pengkomputeran awan tanpa perlu mengurus dan mengoptimumkan infrastruktur untuk skalabiliti. Ini juga bermakna keselamatan peringkat infrastruktur tidak lagi menjadi kebimbangan anda, kelebihan yang besar memandangkan kesukaran dan kerumitan mematuhi piawaian keselamatan. Akhir sekali, anda tidak perlu membeli infrastruktur yang disediakan kepada anda.
Tanpa pelayan boleh dianggap sebagai "keadaan fikiran": pemikiran tertentu semasa mereka bentuk penyelesaian. Elakkan pendekatan yang memerlukan penyelenggaraan sebarang infrastruktur. Dengan pendekatan tanpa pelayan, kami meluangkan masa untuk menyelesaikan masalah yang memberi kesan secara langsung kepada projek dan memberikan faedah kepada pengguna kami: mencipta logik perniagaan yang mantap, membangunkan antara muka pengguna dan membangunkan API yang mudah suai dan boleh dipercayai.
Contohnya, jika kita boleh mengelak daripada mengurus dan mengekalkan platform carian teks percuma, itulah yang akan kita lakukan. Pendekatan kepada pembangunan aplikasi ini boleh mempercepatkan masa ke pasaran dengan ketara, kerana anda tidak perlu lagi risau 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 biasa dalam komuniti tanpa pelayan. Fungsi harus dianggap sebagai gam untuk perkhidmatan, terkandung dalam modul yang boleh digunakan (bukannya menggunakan keseluruhan perpustakaan atau aplikasi web). Ini membolehkan pengurusan penempatan dan perubahan yang sangat terperinci pada aplikasi. Jika anda tidak boleh menggunakan fungsi dengan cara ini, ini mungkin menunjukkan bahawa fungsi menjalankan terlalu banyak tugas dan perlu difaktorkan semula.
Sesetengah orang ditangguhkan oleh penguncian vendor apabila membangunkan aplikasi awan. Perkara yang sama berlaku untuk 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 menyambungkan perkhidmatan AWS yang lain, adalah sebahagian daripada kekuatan seni bina tanpa pelayan. Ia merupakan contoh sinergi yang hebat, di mana hasil gabungan adalah lebih besar daripada jumlah bahagiannya. Cuba untuk mengelakkan penguncian vendor boleh membawa kepada masalah yang lebih besar. Dengan bekas, lebih mudah untuk mengurus lapisan abstraksi anda sendiri merentas pembekal awan. Tetapi apabila ia datang kepada penyelesaian tanpa pelayan, usaha itu tidak akan berbaloi, terutamanya jika kecekapan kos menjadi pertimbangan utama. Pastikan anda memahami cara vendor menyediakan penyampaian perkhidmatan. Sesetengah perkhidmatan khusus bergantung pada titik integrasi dengan vendor lain dan mungkin menawarkan sambungan plug-and-play di luar kotak. Lebih mudah untuk menggunakan Lambda daripada titik akhir get laluan API daripada memproksi permintaan kepada bekas atau contoh EC2. Graphcool menyediakan konfigurasi mudah menggunakan Auth0, yang lebih mudah daripada menggunakan alat pengesahan pihak ketiga.
Memilih vendor yang sesuai untuk aplikasi tanpa pelayan anda ialah keputusan seni bina. Apabila membina aplikasi, anda tidak menjangka satu hari akan kembali ke mengurus pelayan. Memilih vendor awan tidak berbeza daripada memilih sama ada untuk menggunakan bekas, pangkalan data atau bahasa pengaturcaraan.
Pertimbangkan:
- Apakah perkhidmatan yang anda perlukan dan mengapa.
- Apakah perkhidmatan yang ditawarkan oleh pembekal awan dan bagaimana anda boleh menyepadukannya dengan penyelesaian FaaS pilihan anda?
- Apakah bahasa pengaturcaraan yang disokong (diketik secara dinamik atau statik, disusun atau ditafsirkan, apakah tanda aras yang tersedia, apakah prestasi permulaan sejuk, apakah ekosistem sumber terbuka, dsb.).
- Apakah keperluan keselamatan anda (SLA, 2FA, OAuth, HTTPS, SSL, dll.)
- Cara mengurus CI/CD dan kitaran pembangunan perisian anda.
- Apakah faedah penyelesaian infrastruktur sebagai kod yang boleh anda manfaatkan?
Jika anda melanjutkan aplikasi sedia ada dan menambah fungsi tanpa pelayan secara berperingkat, ini mungkin mengehadkan 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 secara 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 ia mungkin salah satu sebab utama kejayaan AWS sejak keluaran Lambda pada 2015.
Bilakah tanpa pelayan berguna?
Teknologi tanpa pelayan boleh digunakan hampir di mana-mana sahaja. Walau bagaimanapun, kelebihan mereka tidak terhad kepada senario aplikasi tertentu. Halangan kemasukan untuk pengkomputeran awan adalah sangat rendah hari ini, tepatnya kerana teknologi tanpa pelayan. Jika pembangun mempunyai idea tetapi tidak tahu cara mengurus infrastruktur awan dan mengoptimumkan kos, mereka tidak perlu mengupah jurutera untuk melakukannya. Jika syarikat permulaan ingin membina platform tetapi bimbang tentang kos yang meningkat di luar kawalan, mereka boleh beralih kepada penyelesaian tanpa pelayan dengan mudah.
Terima kasih kepada penjimatan kos dan kebolehskalaan yang mudah, penyelesaian tanpa pelayan sama-sama terpakai untuk kedua-dua sistem dalaman dan luaran, sehinggalah kepada aplikasi web dengan pangkalan pengguna berjuta-juta. Bil diukur dalam sen dan bukannya euro. Menyewa contoh AWS EC2 yang paling asas (t1.micro) selama sebulan berharga €15, walaupun anda tidak menggunakannya (siapa yang pernah terlupa untuk mematikannya?!). Sebagai perbandingan, untuk mencapai tahap perbelanjaan ini dalam tempoh yang sama, anda perlu menjalankan instance Lambda 512 MB selama 1 saat lebih kurang 3 juta kali. Dan jika anda tidak menggunakan ciri ini, anda tidak membayar apa-apa.
Memandangkan teknologi tanpa pelayan bergantung terutamanya pada acara, agak mudah untuk menyepadukan infrastruktur tanpa pelayan ke dalam sistem warisan. Contohnya, menggunakan AWS S3, Lambda dan Kinesis, anda boleh membuat perkhidmatan analitis untuk sistem runcit yang lebih lama yang boleh mengakses data melalui API.
Kebanyakan platform tanpa pelayan menyokong berbilang bahasa. Ini biasanya Python, JavaScript, C#, Java dan Go. Secara amnya, tiada sekatan perpustakaan merentas semua bahasa, jadi anda boleh menggunakan perpustakaan sumber terbuka kegemaran anda. Walau bagaimanapun, yang terbaik adalah untuk mengelakkan penggunaan kebergantungan yang berlebihan untuk memastikan prestasi optimum dan mengelakkan menjejaskan kebolehskalaan besar-besaran aplikasi tanpa pelayan anda. Lebih banyak pakej yang anda perlu muatkan ke dalam bekas, semakin lama permulaan sejuk akan diambil.
Permulaan sejuk ialah apabila bekas, masa jalan dan pengendali ralat mesti dimulakan sebelum digunakan. Ini boleh menyebabkan kelewatan sehingga 3 saat untuk fungsi, yang tidak sesuai untuk pengguna yang tidak sabar. Walau bagaimanapun, permulaan sejuk berlaku pada panggilan pertama, selepas beberapa minit fungsi tidak aktif. Ramai yang menganggap ini sebagai kesulitan kecil yang boleh dielakkan dengan kerap melakukan ping fungsi untuk memastikan ia melahu. Atau mereka mengabaikannya sama sekali.
Walaupun AWS telah dikeluarkanWalau bagaimanapun, pangkalan data SQL tidak sesuai untuk jenis penggunaan ini, kerana ia bergantung pada sambungan untuk melakukan transaksi, yang boleh menjadi halangan dengan trafik AWS Lambda dengan cepat. Walaupun pembangun sentiasa menambah baik Aurora Tanpa Pelayan, dan anda harus mencubanya, penyelesaian NoSQL sepertiNamun, sudah pasti keadaan ini akan berubah tidak lama lagi.
Perkakas juga mengenakan banyak batasan, terutamanya dalam bidang ujian tempatan. Walaupun penyelesaian seperti Docker-Lambda, DynamoDB Local dan LocalStack wujud, mereka memerlukan kerja yang teliti dan sejumlah besar konfigurasi. Walau bagaimanapun, semua projek ini sedang giat dibangunkan, jadi hanya menunggu masa sebelum perkakas mencapai tahap yang kami perlukan.
Kesan Teknologi Tanpa Pelayan terhadap Kitaran Pembangunan
Memandangkan infrastruktur anda hanyalah konfigurasi, anda boleh menentukan dan menggunakan kod menggunakan skrip, seperti skrip shell. Atau anda boleh menggunakan penyelesaian konfigurasi sebagai kod seperti Walaupun perkhidmatan ini tidak menyediakan konfigurasi untuk semua kawasan, ia membenarkan anda menentukan sumber khusus untuk digunakan sebagai fungsi Lambda. Ini bermakna apabila CloudFormation gagal, anda boleh menulis sumber anda sendiri (fungsi Lambda) untuk mengisi jurang. Dengan cara ini, anda boleh melakukan apa sahaja, malah mengkonfigurasi kebergantungan di luar persekitaran AWS anda.
Oleh kerana ini semua hanyalah konfigurasi, anda boleh menetapkan parameter 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 anda untuk mengujinya dalam pengasingan sepenuhnya semasa pembangunan. Ini secara mendadak mempercepatkan maklum balas yang diterima oleh pembangun apabila mereka ingin memahami sama ada kod mereka berfungsi dengan betul dalam persekitaran langsung. Pengurusan tidak perlu risau tentang kos untuk menggunakan berbilang persekitaran, kerana mereka hanya membayar untuk penggunaan sebenar.
DevOps mempunyai lebih sedikit tanggungjawab kerana mereka hanya perlu memastikan pembangun mempunyai konfigurasi yang betul. Mereka tidak perlu lagi mengurus kejadian, pengimbang beban atau kumpulan keselamatan. Oleh itu, istilah NoOps semakin digunakan, walaupun kemahiran konfigurasi infrastruktur masih penting, terutamanya apabila ia berkaitan dengan konfigurasi IAM dan pengoptimuman sumber awan.
Terdapat alat pemantauan dan keterlihatan yang sangat berkuasa seperti Epsagon, Thundra, Dashbird dan IOPipe. Ia membolehkan anda menjejaki keadaan semasa aplikasi tanpa pelayan, menyediakan log dan pengesanan, merekodkan 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 mereka juga membenarkan pengurusan memantau keadaan dalam masa nyata, dengan penggunaan sumber dan ramalan kos turun-ke-saat. Ini adalah lebih sukar untuk dicapai dengan infrastruktur terurus.
Mereka bentuk aplikasi tanpa pelayan adalah jauh lebih mudah kerana anda tidak perlu menggunakan pelayan web, mengurus mesin atau bekas maya, menampal pelayan, sistem pengendalian, gerbang Internet, dsb. Mengasingkan semua tanggungjawab ini membolehkan seni bina tanpa pelayan menumpukan pada perkara yang paling penting—menyelesaikan keperluan perniagaan dan pelanggan.
Walaupun perkakasan mungkin lebih baik (ia bertambah baik setiap hari), pembangun boleh menumpukan pada melaksanakan logik perniagaan dan mengedarkan kerumitan aplikasi secara optimum merentas perkhidmatan yang berbeza dalam seni bina. Pengurusan aplikasi tanpa pelayan didorong oleh peristiwa dan diabstraksikan oleh pembekal awan (cth., SQS, acara S3 atau strim DynamoDB). Oleh itu, pembangun hanya perlu menulis logik perniagaan untuk bertindak balas kepada peristiwa tertentu, tanpa perlu risau tentang cara terbaik untuk melaksanakan pangkalan data dan baris gilir mesej, atau cara mengurus data secara optimum dalam peranti 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 menggunakan konfigurasi tindanan tersuai membolehkan pembangun memperoleh maklum balas penting dengan cepat tanpa perlu risau tentang 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 dan tiada set perkhidmatan untuk tugas ini. AWS kini merupakan peneraju dalam kalangan penyelesaian tanpa pelayan yang berkuasa, tetapi terdapat juga , и Jika anda menggunakan AWS, maka sebagai pendekatan untuk mengumpul aplikasi, kami boleh mengesyorkan (SAM), terutamanya apabila menggunakan C#, kerana Visual Studio mempunyai alat yang sangat baik. SAM CLI boleh melakukan semua yang Visual Studio boleh, jadi anda tidak akan terlepas apa-apa jika anda bertukar 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 menggunakan fail konfigurasi YAML yang berkuasa. Rangka Kerja Tanpa Pelayan juga menyokong pelbagai perkhidmatan awan, jadi kami mengesyorkannya untuk mereka yang mencari penyelesaian berbilang awan. Ia mempunyai komuniti besar yang telah mencipta satu tan pemalam untuk sebarang keperluan.
Alat sumber terbuka seperti Docker-Lambda, Serverless Local, DynamoDB Local dan LocalStack sangat sesuai untuk ujian tempatan. Teknologi tanpa pelayan masih di peringkat awal, begitu juga dengan alatan untuk mereka, jadi menyesuaikannya untuk senario ujian yang kompleks boleh menjadi mencabar. Walau bagaimanapun, hanya menggunakan timbunan dalam persekitaran dan menguji di sana adalah sangat murah. Dan anda tidak perlu membuat salinan tempatan yang tepat bagi persekitaran awan.
Untuk mengurangkan saiz pakej yang digunakan dan mempercepatkan masa pemuatan, gunakan AWS Lambda Layers.
Gunakan bahasa pengaturcaraan yang betul untuk tugasan yang betul. Bahasa yang berbeza mempunyai kelebihan dan kekurangan mereka sendiri. Terdapat banyak penanda aras, tetapi JavaScript, Python dan C# (.NET Core 2.1+) adalah peneraju dalam prestasi AWS Lambda. AWS Lambda baru-baru ini memperkenalkan API Runtime yang membolehkan anda menentukan bahasa pilihan anda dan persekitaran masa jalan, jadi jangan ragu untuk mencuba.
Pastikan pakej penggunaan kecil. Lebih kecil ia, lebih cepat ia dimuatkan. Elakkan menggunakan perpustakaan yang besar, terutamanya jika anda hanya menggunakan beberapa ciri daripadanya. Jika anda pengaturcaraan dalam JavaScript, gunakan alat binaan seperti Webpack untuk mengoptimumkan binaan anda dan sertakan perkara yang anda perlukan sahaja. .NET Core 3.0 termasuk QuickJit dan Kompilasi Berperingkat, yang meningkatkan prestasi dan sangat membantu dengan permulaan yang dingin.
Sifat didorong peristiwa bagi fungsi tanpa pelayan pada mulanya boleh menjadikan penyelarasan logik perniagaan mencabar. Di sinilah baris gilir mesej dan mesin keadaan boleh menjadi sangat berguna. Fungsi Lambda boleh memanggil satu sama lain, tetapi hanya berbuat demikian 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 mengendalikan transaksi (menggunakan baris gilir FIFO). Fungsi AWS Lambda boleh dilampirkan pada baris gilir SQS sebagai baris gilir mesej "mati", yang menjejaki mesej yang gagal untuk analisis kemudian. Fungsi Langkah AWS (mesin keadaan) sangat berguna untuk mengurus proses kompleks yang memerlukan fungsi rantaian. Daripada fungsi Lambda yang menggunakan fungsi lain, fungsi Step 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
Teknologi tanpa pelayan telah berkembang pada kadar yang tidak pernah berlaku sebelum ini dalam beberapa tahun kebelakangan ini. Anjakan paradigma ini bukan tanpa tanggapan yang salah. Dengan mengabstraksi infrastruktur dan penskalaan, penyelesaian tanpa pelayan menawarkan faedah yang ketara, daripada pembangunan yang dipermudahkan dan proses DevOps kepada pengurangan kos operasi dengan ketara.
Walaupun pendekatan tanpa pelayan bukan tanpa kelemahannya, terdapat corak dan metodologi 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
