គន្លឹះ និងធនធានសម្រាប់បង្កើតកម្មវិធី serverless

ទោះបីជាបច្ចេកវិទ្យា serverless ទទួលបានប្រជាប្រិយភាពយ៉ាងឆាប់រហ័សក្នុងប៉ុន្មានឆ្នាំចុងក្រោយនេះក៏ដោយ ក៏នៅតែមានការយល់ខុស និងការភ័យខ្លាចជាច្រើនដែលទាក់ទងនឹងពួកគេ។ ភាពអាស្រ័យរបស់អ្នកលក់ ឧបករណ៍ ការគ្រប់គ្រងថ្លៃដើម ការចាប់ផ្តើមត្រជាក់ ការត្រួតពិនិត្យ និងវដ្តជីវិតនៃការអភិវឌ្ឍន៍ គឺជាប្រធានបទដ៏ក្តៅគគុកនៅពេលនិយាយអំពីបច្ចេកវិទ្យាដែលគ្មានម៉ាស៊ីនមេ។ នៅក្នុងអត្ថបទនេះ យើងនឹងស្វែងយល់អំពីប្រធានបទមួយចំនួនដែលបានរៀបរាប់ ក៏ដូចជាចែករំលែកគន្លឹះ និងតំណភ្ជាប់ទៅកាន់ប្រភពព័ត៌មានមានប្រយោជន៍ ដើម្បីជួយអ្នកចាប់ផ្តើមបង្កើតកម្មវិធីគ្មានម៉ាស៊ីនមេដ៏មានឥទ្ធិពល បត់បែន និងសន្សំសំចៃ។

ការយល់ខុសអំពីបច្ចេកវិទ្យាគ្មានម៉ាស៊ីនមេ

មនុស្ស​ជា​ច្រើន​គិត​ថា​ដំណើរការ​គ្មាន​ម៉ាស៊ីន​បម្រើ និង​គ្មាន​ម៉ាស៊ីន​បម្រើ (មុខងារជាសេវាកម្ម, FaaS ) គឺស្ទើរតែដូចគ្នា។ នេះមានន័យថា ភាពខុសប្លែកគ្នាមិនអស្ចារ្យពេកទេ ហើយវាមានតម្លៃក្នុងការបង្ហាញពីភាពថ្មីថ្មោង។ ទោះបីជា AWS Lambda គឺជាតារាមួយនៃសម័យកាលដែលគ្មានម៉ាស៊ីនមេ និងជាធាតុដ៏ពេញនិយមបំផុតមួយនៃស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេក៏ដោយ ស្ថាបត្យកម្មនេះមានច្រើនជាង FaaS ។

គោលការណ៍ជាមូលដ្ឋាននៅពីក្រោយបច្ចេកវិទ្យា serverless គឺថាអ្នកមិនចាំបាច់ព្រួយបារម្ភអំពីការគ្រប់គ្រង និងពង្រីកហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកទេ អ្នកគ្រាន់តែចំណាយលើអ្វីដែលអ្នកប្រើប៉ុណ្ណោះ។ សេវាកម្មជាច្រើនសមនឹងលក្ខណៈវិនិច្ឆ័យទាំងនេះ - AWS DynamoDB, S3, SNS ឬ SQS, Graphcool, Auth0, Now, Netlify, Firebase និងផ្សេងៗទៀត។ ជាទូទៅ ការប្រើប្រាស់ serverless មានន័យថាប្រើប្រាស់ថាមពលពេញលេញនៃ cloud computing ដោយមិនចាំបាច់គ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ និងបង្កើនប្រសិទ្ធភាពវាសម្រាប់ការធ្វើមាត្រដ្ឋាន។ វាក៏មានន័យផងដែរថាសន្តិសុខនៅកម្រិតហេដ្ឋារចនាសម្ព័ន្ធលែងជាកង្វល់របស់អ្នកទៀតហើយ ដែលជាអត្ថប្រយោជន៍ដ៏ធំធេងដោយសារភាពលំបាក និងភាពស្មុគស្មាញនៃការបំពេញតាមស្តង់ដារសុវត្ថិភាព។ ចុងក្រោយ អ្នកមិនចាំបាច់ទិញហេដ្ឋារចនាសម្ព័ន្ធដែលផ្តល់ឱ្យអ្នកទេ។

Serverless អាច​ត្រូវ​បាន​គេ​ចាត់​ទុក​ថា​ជា "ស្ថានភាព​នៃ​ចិត្ត": ចិត្ត​គំនិត​មួយ​ចំនួន​នៅ​ពេល​ដែល​ការ​រចនា​ដំណោះ​ស្រាយ. ជៀសវាងវិធីសាស្រ្តដែលត្រូវការការថែទាំហេដ្ឋារចនាសម្ព័ន្ធណាមួយ។ ជាមួយនឹងវិធីសាស្រ្តគ្មានម៉ាស៊ីនមេ យើងចំណាយពេលដោះស្រាយកិច្ចការដែលប៉ះពាល់ដល់គម្រោងដោយផ្ទាល់ និងនាំមកនូវអត្ថប្រយោជន៍ដល់អ្នកប្រើប្រាស់របស់យើង៖ យើងបង្កើតតក្កវិជ្ជាអាជីវកម្មប្រកបដោយនិរន្តរភាព បង្កើតចំណុចប្រទាក់អ្នកប្រើប្រាស់ និងបង្កើត APIs ដែលអាចបត់បែនបាន និងអាចទុកចិត្តបាន។

ឧទាហរណ៍ ប្រសិនបើវាអាចធ្វើទៅបានដើម្បីជៀសវាងការគ្រប់គ្រង និងរក្សាវេទិកាស្វែងរកអត្ថបទឥតគិតថ្លៃ នោះជាអ្វីដែលយើងនឹងធ្វើ។ វិធីសាស្រ្តក្នុងការបង្កើតកម្មវិធីនេះអាចបង្កើនល្បឿនពេលវេលាទៅកាន់ទីផ្សារយ៉ាងខ្លាំង ពីព្រោះអ្នកមិនចាំបាច់គិតអំពីការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធស្មុគស្មាញទៀតទេ។ លុបបំបាត់ទំនួលខុសត្រូវ និងការចំណាយនៃការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ ហើយផ្តោតលើការកសាងកម្មវិធី និងសេវាកម្មដែលអតិថិជនអ្នកត្រូវការ។ Patrick Debois បានហៅវិធីសាស្រ្តនេះ។ 'សេវាកម្ម'ពាក្យនេះត្រូវបានអនុម័តនៅក្នុងសហគមន៍ដែលគ្មានម៉ាស៊ីនមេ។ មុខងារគួរតែត្រូវបានគេគិតថាជាតំណភ្ជាប់ទៅកាន់សេវាកម្មជាម៉ូឌុលដែលអាចដាក់ឱ្យប្រើប្រាស់បាន (ជំនួសឱ្យការដាក់ពង្រាយបណ្ណាល័យទាំងមូល ឬកម្មវិធីគេហទំព័រ)។ នេះផ្តល់នូវភាពលម្អិតមិនគួរឱ្យជឿសម្រាប់ការគ្រប់គ្រងការដាក់ពង្រាយ និងការផ្លាស់ប្តូរកម្មវិធី។ ប្រសិនបើអ្នកមិនអាចដាក់ពង្រាយមុខងារតាមវិធីនេះទេ នោះវាអាចបង្ហាញថាមុខងារបំពេញការងារច្រើនពេក ហើយចាំបាច់ត្រូវជួសជុលឡើងវិញ។

អ្នកខ្លះមានការភ័ន្តច្រឡំដោយការពឹងផ្អែកលើអ្នកលក់នៅពេលបង្កើតកម្មវិធីពពក។ ដូចគ្នានេះដែរគឺជាការពិតជាមួយនឹងបច្ចេកវិទ្យា serverless ហើយនេះស្ទើរតែជាការយល់ខុស។ នៅក្នុងបទពិសោធន៍របស់យើង ការកសាងកម្មវិធីគ្មានម៉ាស៊ីនមេនៅលើ AWS រួមជាមួយនឹងសមត្ថភាពរបស់ AWS Lambda ក្នុងការចងក្រងសេវាកម្ម AWS ផ្សេងទៀតរួមគ្នា គឺជាផ្នែកមួយនៃភាពរឹងមាំនៃស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេ។ នេះគឺជាឧទាហរណ៍ដ៏ល្អនៃការរួមបញ្ចូលគ្នា នៅពេលដែលលទ្ធផលនៃការរួមបញ្ចូលគ្នាគឺច្រើនជាងផលបូកនៃលក្ខខណ្ឌ។ ការព្យាយាមជៀសវាងការពឹងផ្អែករបស់អ្នកលក់អាចប្រឈមនឹងបញ្ហាកាន់តែច្រើន។ នៅពេលធ្វើការជាមួយកុងតឺន័រ វាកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រងស្រទាប់អរូបីផ្ទាល់ខ្លួនរបស់អ្នករវាងអ្នកផ្តល់សេវាពពក។ ប៉ុន្តែនៅពេលនិយាយអំពីដំណោះស្រាយដែលគ្មានម៉ាស៊ីនមេ កិច្ចខិតខំប្រឹងប្រែងនឹងមិនទទួលបានទេ ជាពិសេសប្រសិនបើប្រសិទ្ធភាពចំណាយត្រូវយកមកពិចារណាតាំងពីដំបូង។ ត្រូវប្រាកដថារកមើលពីរបៀបដែលអ្នកលក់ផ្តល់សេវាកម្ម។ សេវាកម្មឯកទេសមួយចំនួនពឹងផ្អែកលើចំណុចរួមបញ្ចូលជាមួយអ្នកលក់ផ្សេងទៀត ហើយអាចផ្តល់នូវការតភ្ជាប់ដោត និងលេងចេញពីប្រអប់។ វាងាយស្រួលជាងក្នុងការផ្តល់នូវការហៅទូរសព្ទ Lambda ពីចំណុចបញ្ចប់ API gateway ជាជាងការប្រូកស៊ីសំណើទៅកាន់កុងតឺន័រ ឬ EC2 មួយចំនួន។ Graphcool ផ្តល់នូវការកំណត់រចនាសម្ព័ន្ធងាយស្រួលជាមួយ Auth0 ដែលងាយស្រួលជាងការប្រើឧបករណ៍ផ្ទៀងផ្ទាត់ភាគីទីបី។

ការជ្រើសរើសអ្នកលក់ដែលត្រឹមត្រូវសម្រាប់កម្មវិធី serverless របស់អ្នកគឺជាការសម្រេចចិត្តស្ថាបត្យកម្ម។ នៅពេលអ្នកបង្កើតកម្មវិធី អ្នកមិនរំពឹងថាថ្ងៃណាមួយនឹងត្រលប់ទៅគ្រប់គ្រងម៉ាស៊ីនមេនោះទេ។ ការជ្រើសរើសអ្នកលក់ cloud គឺមិនខុសពីការជ្រើសរើសប្រើប្រាស់ containers ឬ database ឬសូម្បីតែ programming language នោះទេ។

ពិចារណា៖

• តើអ្នកត្រូវការសេវាកម្មអ្វីខ្លះ ហើយហេតុអ្វី។
• សេវាកម្មអ្វីខ្លះដែលអ្នកផ្តល់សេវាពពកផ្តល់ និងរបៀបដែលអ្នកអាចផ្សំពួកវាជាមួយដំណោះស្រាយ FaaS ដែលបានជ្រើសរើសរបស់អ្នក។
• តើភាសាសរសេរកម្មវិធីណាខ្លះត្រូវបានគាំទ្រ (ជាមួយការវាយអក្សរថាមវន្ត ឬឋិតិវន្ត ចងក្រង ឬបកស្រាយ តើអ្វីជាគោល អ្វីជាការអនុវត្តនៅពេលចាប់ផ្តើមត្រជាក់ តើអ្វីជាប្រព័ន្ធអេកូប្រភពបើកចំហ។ល។)។
• តើអ្វីទៅជាតម្រូវការសុវត្ថិភាពរបស់អ្នក (SLA, 2FA, OAuth, HTTPS, SSL ។ល។)
• របៀបគ្រប់គ្រង CI/CD និងវដ្តនៃការអភិវឌ្ឍន៍កម្មវិធីរបស់អ្នក។
• ដំណោះស្រាយហេដ្ឋារចនាសម្ព័ន្ធដូចកូដណាមួយដែលអ្នកអាចទាញយកអត្ថប្រយោជន៍ពី។

ប្រសិនបើអ្នកពង្រីកកម្មវិធីដែលមានស្រាប់ ហើយបន្ថែមមុខងារគ្មានម៉ាស៊ីនមេ វាអាចកម្រិតសមត្ថភាពដែលមានខ្លះ។ ទោះជាយ៉ាងណាក៏ដោយ បច្ចេកវិទ្យាស្ទើរតែទាំងអស់ដែលមិនមានម៉ាស៊ីនមេផ្តល់នូវប្រភេទនៃ API មួយចំនួន (តាមរយៈ REST ឬជួរសារ) ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតផ្នែកបន្ថែមដោយឯករាជ្យនៃស្នូលកម្មវិធី និងជាមួយនឹងការរួមបញ្ចូលយ៉ាងងាយស្រួល។ ស្វែងរកសេវាកម្មដែលមាន APIs ច្បាស់លាស់ ឯកសារល្អ និងសហគមន៍រឹងមាំ ហើយអ្នកមិនអាចខុសបានទេ។ ភាពងាយស្រួលក្នុងការធ្វើសមាហរណកម្មជារឿយៗអាចជារង្វាស់សំខាន់ ហើយប្រហែលជាមូលហេតុចម្បងមួយដែល AWS ទទួលបានជោគជ័យខ្លាំងចាប់តាំងពី Lambda ត្រូវបានចេញផ្សាយក្នុងឆ្នាំ 2015។

នៅពេលដែល Serverless គឺល្អ។

បច្ចេកវិទ្យាគ្មានម៉ាស៊ីនមេអាចត្រូវបានអនុវត្តស្ទើរតែគ្រប់ទីកន្លែង។ ទោះជាយ៉ាងណាក៏ដោយគុណសម្បត្តិរបស់ពួកគេមិនត្រូវបានកំណត់ចំពោះតែវិធីមួយនៃការដាក់ពាក្យនោះទេ។ ឧបសគ្គក្នុងការចូលសម្រាប់ cloud computing សព្វថ្ងៃនេះគឺទាបណាស់ ដោយសារបច្ចេកវិទ្យា serverless ។ ប្រសិនបើអ្នកអភិវឌ្ឍន៍មានគំនិតមួយ ប៉ុន្តែពួកគេមិនដឹងពីរបៀបគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធពពក និងបង្កើនប្រសិទ្ធភាពការចំណាយនោះ ពួកគេមិនចាំបាច់ស្វែងរកវិស្វករប្រភេទណាមួយដើម្បីធ្វើវានោះទេ។ ប្រសិនបើការចាប់ផ្តើមអាជីវកម្មចង់បង្កើតវេទិកាមួយ ប៉ុន្តែខ្លាចថាការចំណាយអាចនឹងអស់ការគ្រប់គ្រង ពួកគេអាចងាកទៅរកដំណោះស្រាយដែលគ្មានម៉ាស៊ីនមេបានយ៉ាងងាយស្រួល។

ដោយសារតែការសន្សំសំចៃថ្លៃដើម និងភាពងាយស្រួលនៃការធ្វើមាត្រដ្ឋាន ដំណោះស្រាយគ្មានម៉ាស៊ីនមេអាចអនុវត្តបានស្មើៗគ្នាសម្រាប់ទាំងប្រព័ន្ធខាងក្នុង និងខាងក្រៅ រហូតដល់កម្មវិធីគេហទំព័រដែលមានទស្សនិកជនច្រើនលាននាក់។ គណនីត្រូវបានវាស់វែងជាជាងគិតជាប្រាក់អឺរ៉ូ ប៉ុន្តែគិតជាសេន។ ការជួលឧទាហរណ៍សាមញ្ញបំផុតនៃ AWS EC2 (t1.micro) សម្រាប់មួយខែនឹងត្រូវចំណាយអស់ 15 អឺរ៉ូ ទោះបីជាអ្នកមិនធ្វើអ្វីជាមួយវាក៏ដោយ (អ្នកណាមិនភ្លេចបិទវា?!)។ នៅក្នុងការប្រៀបធៀប ដើម្បីឈានដល់កម្រិតនៃការចំណាយនេះក្នុងរយៈពេលដូចគ្នា អ្នកត្រូវដំណើរការ Lambda 512 MB សម្រាប់ 1 វិនាទីប្រហែល 3 លានដង។ ហើយប្រសិនបើអ្នកមិនប្រើមុខងារនេះទេ នោះអ្នកនឹងមិនបង់ប្រាក់អ្វីនោះទេ។

ដោយសារតែ serverless ត្រូវបានជំរុញដោយព្រឹត្តិការណ៍ជាចម្បង វាពិតជាងាយស្រួលណាស់ក្នុងការបន្ថែមហេដ្ឋារចនាសម្ព័ន្ធគ្មាន server ទៅប្រព័ន្ធចាស់ៗ។ ឧទាហរណ៍ ដោយប្រើ AWS S3, Lambda និង Kinesis អ្នកអាចបង្កើតសេវាកម្មវិភាគសម្រាប់ប្រព័ន្ធលក់រាយចាស់ដែលអាចទទួលទិន្នន័យតាមរយៈ API ។

វេទិកាគ្មានម៉ាស៊ីនមេភាគច្រើនគាំទ្រភាសាច្រើន។ ភាគច្រើនវាគឺជា Python, JavaScript, C#, Java និង Go ។ ជាធម្មតាមិនមានការរឹតបន្តឹងលើការប្រើប្រាស់បណ្ណាល័យគ្រប់ភាសាទេ ដូច្នេះអ្នកអាចប្រើបណ្ណាល័យប្រភពបើកចំហដែលអ្នកចូលចិត្តបាន។ ទោះជាយ៉ាងណាក៏ដោយ វាត្រូវបានណែនាំមិនឱ្យបំពានលើភាពអាស្រ័យ ដូច្នេះមុខងាររបស់អ្នកដំណើរការបានល្អបំផុត ហើយកុំបដិសេធអត្ថប្រយោជន៍នៃទំហំដ៏ធំនៃកម្មវិធីដែលគ្មានម៉ាស៊ីនមេរបស់អ្នក។ កញ្ចប់កាន់តែច្រើនដែលត្រូវការផ្ទុកទៅក្នុងកុងតឺន័រ ការចាប់ផ្តើមត្រជាក់នឹងចំណាយពេលយូរ។

ការចាប់ផ្តើមត្រជាក់គឺនៅពេលដែលអ្នកត្រូវការចាប់ផ្តើមកុងតឺន័រ ពេលវេលាដំណើរការ និងឧបករណ៍ដោះស្រាយកំហុសមុននឹងប្រើវា។ ដោយសារតែនេះ ការពន្យាពេលក្នុងការអនុវត្តមុខងារអាចមានរយៈពេលរហូតដល់ 3 វិនាទី ហើយនេះមិនមែនជាជម្រើសដ៏ល្អបំផុតសម្រាប់អ្នកប្រើប្រាស់ដែលមិនចេះអត់ធ្មត់នោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ ភាពត្រជាក់ចាប់ផ្តើមកើតឡើងនៅពេលហៅទូរសព្ទលើកដំបូងបន្ទាប់ពីមុខងារទំនេរពីរបីនាទី។ ដូច្នេះមនុស្សជាច្រើនចាត់ទុកថានេះជាការរំខានតិចតួចដែលអាចត្រូវបានដោះស្រាយដោយការបិទមុខងារជាទៀងទាត់ដើម្បីរក្សាវាឱ្យនៅទំនេរ។ ឬពួកគេមិនអើពើទិដ្ឋភាពនេះទាំងស្រុង។

ទោះបីជា AWS បានចេញផ្សាយ មូលដ្ឋានទិន្នន័យ SQL គ្មានម៉ាស៊ីនមេ Serverless Auroraទោះជាយ៉ាងណាក៏ដោយ មូលដ្ឋានទិន្នន័យ SQL គឺមិនល្អសម្រាប់កម្មវិធីនេះទេ ដោយសារវាអាស្រ័យលើការតភ្ជាប់ដើម្បីធ្វើប្រតិបត្តិការ ដែលអាចក្លាយជាឧបសគ្គយ៉ាងឆាប់រហ័សជាមួយនឹងចរាចរណ៍ដ៏ច្រើននៅលើ AWS Lambda។ បាទ អ្នកអភិវឌ្ឍន៍កំពុងកែលម្អ Serverless Aurora ឥតឈប់ឈរ ហើយអ្នកគួរតែសាកល្បងជាមួយវា ប៉ុន្តែសព្វថ្ងៃនេះដំណោះស្រាយ NoSQL ដូចជា DynamoDB. ទោះជាយ៉ាងណាក៏ដោយ មានការសង្ស័យថាស្ថានភាពនេះនឹងផ្លាស់ប្តូរក្នុងពេលឆាប់ៗនេះ។

កញ្ចប់ឧបករណ៍ក៏ដាក់កម្រិតជាច្រើនផងដែរ ជាពិសេសនៅក្នុងផ្នែកនៃការធ្វើតេស្តក្នុងស្រុក។ ទោះបីជាមានដំណោះស្រាយដូចជា Docker-Lambda, DynamoDB Local និង LocalStack ក៏ដោយ ក៏ពួកគេទាមទារការខិតខំប្រឹងប្រែង និងការកំណត់រចនាសម្ព័ន្ធយ៉ាងច្រើន។ ទោះជាយ៉ាងណាក៏ដោយ គម្រោងទាំងអស់នេះត្រូវបានអភិវឌ្ឍយ៉ាងសកម្ម ដូច្នេះវាគ្រាន់តែជាបញ្ហានៃពេលវេលាប៉ុណ្ណោះ មុនពេលប្រអប់ឧបករណ៍ឈានដល់កម្រិតដែលយើងត្រូវការ។

ផលប៉ះពាល់នៃបច្ចេកវិទ្យា serverless លើវដ្តនៃការអភិវឌ្ឍន៍

ដោយសារតែហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកគ្រាន់តែជាការកំណត់ប៉ុណ្ណោះ អ្នកអាចកំណត់ និងដាក់ឱ្យប្រើប្រាស់កូដដោយប្រើស្គ្រីប ដូចជាស្គ្រីបសែលជាដើម។ ឬ​អ្នក​អាច​ងាក​ទៅ​រក​ដំណោះស្រាយ​ថ្នាក់​កំណត់​រចនាសម្ព័ន្ធ​ដូច​ជា​កូដ​ដូច​ជា AWS CloudFormation . ទោះបីជាសេវាកម្មនេះមិនផ្តល់ការកំណត់រចនាសម្ព័ន្ធសម្រាប់គ្រប់ផ្នែកទាំងអស់ក៏ដោយ ប៉ុន្តែវាអនុញ្ញាតឱ្យអ្នកកំណត់ធនធានជាក់លាក់ដើម្បីប្រើប្រាស់ជាមុខងារ Lambda ។ នោះហើយជាកន្លែងដែល CloudFormation បរាជ័យ អ្នកអាចសរសេរធនធានផ្ទាល់ខ្លួនរបស់អ្នក (មុខងារ Lambda) ដែលនឹងបិទគម្លាតនេះ។ វិធីនេះអ្នកអាចធ្វើអ្វីៗបាន សូម្បីតែកំណត់រចនាសម្ព័ន្ធភាពអាស្រ័យនៅខាងក្រៅបរិយាកាស AWS របស់អ្នក។

ដោយសារតែវាគ្រាន់តែជាការកំណត់ប៉ុណ្ណោះ អ្នកអាចប្ដូរស្គ្រីបដាក់ឱ្យប្រើប្រាស់របស់អ្នកតាមបំណងសម្រាប់បរិស្ថាន តំបន់ និងអ្នកប្រើប្រាស់ជាក់លាក់ ជាពិសេសប្រសិនបើអ្នកកំពុងប្រើដំណោះស្រាយហេដ្ឋារចនាសម្ព័ន្ធដូចកូដដូចជា CloudFormation។ ឧទាហរណ៍ អ្នកអាចដាក់ពង្រាយច្បាប់ចម្លងនៃហេដ្ឋារចនាសម្ព័ន្ធសម្រាប់សាខានីមួយៗនៅក្នុងឃ្លាំង ដូច្នេះអ្នកអាចសាកល្បងពួកវាទាំងស្រុងដោយឯកោកំឡុងពេលអភិវឌ្ឍ។ នេះបង្កើនល្បឿនមតិកែលម្អយ៉ាងខ្លាំងសម្រាប់អ្នកអភិវឌ្ឍន៍ នៅពេលដែលពួកគេចង់យល់ថាតើកូដរបស់ពួកគេដំណើរការបានគ្រប់គ្រាន់នៅក្នុងបរិយាកាសផ្ទាល់ឬអត់។ អ្នកគ្រប់គ្រងមិនចាំបាច់ព្រួយបារម្ភអំពីតម្លៃនៃការដាក់ពង្រាយបរិស្ថានច្រើននោះទេ ព្រោះពួកគេចំណាយត្រឹមតែសម្រាប់ការប្រើប្រាស់ជាក់ស្តែងប៉ុណ្ណោះ។

DevOps មានការព្រួយបារម្ភតិចជាងព្រោះពួកគេគ្រាន់តែត្រូវការធ្វើឱ្យប្រាកដថាអ្នកអភិវឌ្ឍន៍មានការកំណត់ត្រឹមត្រូវ។ អ្នកលែងត្រូវការគ្រប់គ្រង instances, balancers, ឬ security group។ ដូច្នេះហើយ ពាក្យ NoOps ត្រូវបានប្រើប្រាស់កាន់តែខ្លាំងឡើង ទោះបីជាវានៅតែមានសារៈសំខាន់ដើម្បីអាចកំណត់រចនាសម្ព័ន្ធហេដ្ឋារចនាសម្ព័ន្ធ ជាពិសេសនៅពេលនិយាយអំពីការកំណត់រចនាសម្ព័ន្ធ IAM និងការបង្កើនប្រសិទ្ធភាពធនធានពពក។

មានឧបករណ៍ត្រួតពិនិត្យ និងមើលឃើញដ៏មានឥទ្ធិពលដូចជា Epsagon, Thundra, Dashbird និង IOPipe ។ ពួកគេអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យស្ថានភាពបច្ចុប្បន្ននៃកម្មវិធីដែលមិនមានម៉ាស៊ីនមេរបស់អ្នក ផ្តល់នូវការកត់ត្រា និងការតាមដាន ការចាប់យករង្វាស់នៃការអនុវត្ត និងបញ្ហាស្ថាបត្យកម្ម ធ្វើការវិភាគការចំណាយ និងការព្យាករណ៍ និងច្រើនទៀត។ ពួកគេមិនត្រឹមតែផ្តល់ឱ្យវិស្វករ អ្នកអភិវឌ្ឍន៍ និងស្ថាបត្យករ DevOps នូវទិដ្ឋភាពដ៏ទូលំទូលាយនៃការអនុវត្តកម្មវិធីប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងតាមដានស្ថានភាពក្នុងពេលវេលាជាក់ស្តែង ជាមួយនឹងការចំណាយធនធាន និងការព្យាករណ៍តម្លៃក្នុងមួយវិនាទី។ វាពិបាកជាងក្នុងការរៀបចំវាជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធដែលបានគ្រប់គ្រង។

ការរចនាកម្មវិធីដែលមិនមានម៉ាស៊ីនមេគឺងាយស្រួលជាង ដោយសារអ្នកមិនចាំបាច់ដាក់ពង្រាយម៉ាស៊ីនមេគេហទំព័រ គ្រប់គ្រងម៉ាស៊ីននិម្មិត ឬកុងតឺន័រ ម៉ាស៊ីនមេបំណះ ប្រព័ន្ធប្រតិបត្តិការ ច្រកផ្លូវអ៊ីនធឺណិត។ល។ តាមរយៈការដកយកទំនួលខុសត្រូវទាំងអស់នេះ ស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេអាចផ្តោតលើស្នូល - ដំណោះស្រាយ អាជីវកម្ម និងតម្រូវការអតិថិជន។

ខណៈពេលដែលប្រអប់ឧបករណ៍អាចប្រសើរជាងនេះ (វាកាន់តែប្រសើរឡើងជារៀងរាល់ថ្ងៃ) អ្នកអភិវឌ្ឍន៍អាចផ្តោតលើការអនុវត្តតក្កវិជ្ជាអាជីវកម្ម និងចែកចាយយ៉ាងល្អបំផុតនូវភាពស្មុគស្មាញនៃកម្មវិធីតាមរយៈសេវាកម្មផ្សេងៗគ្នានៅក្នុងស្ថាបត្យកម្ម។ ការគ្រប់គ្រងកម្មវិធីគ្មានម៉ាស៊ីនមេគឺផ្អែកលើព្រឹត្តិការណ៍ និងអរូបីដោយអ្នកផ្តល់សេវាពពក (ឧទាហរណ៍ ព្រឹត្តិការណ៍ SQS, S3 ឬស្ទ្រីម DynamoDB)។ ដូច្នេះ អ្នកអភិវឌ្ឍន៍គ្រាន់តែត្រូវការសរសេរតក្កវិជ្ជាអាជីវកម្មដើម្បីឆ្លើយតបទៅនឹងព្រឹត្តិការណ៍ជាក់លាក់ ហើយមិនចាំបាច់ព្រួយបារម្ភអំពីរបៀបដែលល្អបំផុតក្នុងការអនុវត្តមូលដ្ឋានទិន្នន័យ និងជួរសារ ឬរបៀបរៀបចំការងារដ៏ល្អប្រសើរជាមួយទិន្នន័យនៅក្នុងកន្លែងផ្ទុកផ្នែករឹងជាក់លាក់។

កូដអាចត្រូវបានដំណើរការ និងបំបាត់កំហុសក្នុងមូលដ្ឋាន ដូចជាដំណើរការអភិវឌ្ឍន៍ណាមួយ។ ការធ្វើតេស្តឯកតានៅតែដដែល។ សមត្ថភាពក្នុងការដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីទាំងមូលជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធជង់ផ្ទាល់ខ្លួនអនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍន៍ទទួលបានមតិកែលម្អសំខាន់ៗយ៉ាងឆាប់រហ័សដោយមិនគិតពីតម្លៃនៃការធ្វើតេស្ត ឬផលប៉ះពាល់លើបរិស្ថានដែលមានតម្លៃថ្លៃ។

ឧបករណ៍ និងបច្ចេកទេសសម្រាប់បង្កើតកម្មវិធី serverless

មិនមានវិធីជាក់លាក់ក្នុងការបង្កើតកម្មវិធី serverless ទេ។ ក៏ដូចជាសំណុំនៃសេវាកម្មសម្រាប់កិច្ចការនេះ។ AWS គឺជាអ្នកនាំមុខគេក្នុងចំណោមដំណោះស្រាយ serverless ដ៏មានឥទ្ធិពលនាពេលបច្ចុប្បន្ននេះ ប៉ុន្តែសូមក្រឡេកមើលផងដែរ។ Google Cloud , Zeit ។ и Firebase. ប្រសិនបើអ្នកកំពុងប្រើ AWS នោះវិធីសាស្ត្រដែលបានណែនាំសម្រាប់ការប្រមូលកម្មវិធីគឺ គំរូកម្មវិធីគ្មានម៉ាស៊ីនមេ (SAM) ជាពិសេសនៅពេលប្រើ C# ពីព្រោះ Visual Studio មានឧបករណ៍ដ៏អស្ចារ្យ។ SAM CLI អាចធ្វើអ្វីគ្រប់យ៉ាងដែល Visual Studio អាចធ្វើបាន ដូច្នេះអ្នកនឹងមិនបាត់បង់អ្វីទាំងអស់ ប្រសិនបើអ្នកប្តូរទៅ IDE ឬកម្មវិធីនិពន្ធអត្ថបទផ្សេងទៀត។ ជាការពិតណាស់ SAM ធ្វើការជាមួយភាសាផ្សេងទៀតផងដែរ។

ប្រសិនបើអ្នកកំពុងសរសេរជាភាសាផ្សេងទៀត Serverless Framework គឺជាឧបករណ៍ប្រភពបើកចំហដ៏ល្អដែលអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធអ្វីទាំងអស់ជាមួយនឹងឯកសារកំណត់រចនាសម្ព័ន្ធ YAML ដែលមានអនុភាពខ្លាំង។ Serverless Framework ក៏គាំទ្រសេវាកម្ម cloud ផ្សេងៗផងដែរ ដូច្នេះហើយយើងណែនាំវាដល់អ្នកដែលកំពុងស្វែងរកដំណោះស្រាយពហុពពក។ វាមានសហគមន៍ដ៏ធំមួយដែលបានបង្កើតកម្មវិធីជំនួយជាច្រើនសម្រាប់តម្រូវការណាមួយ។

សម្រាប់ការធ្វើតេស្តក្នុងស្រុក ឧបករណ៍ប្រភពបើកចំហ Docker-Lambda, Serverless Local, DynamoDB Local និង LocalStack គឺសមល្អ។ បច្ចេកវិទ្យាគ្មានម៉ាស៊ីនមេនៅតែស្ថិតក្នុងដំណាក់កាលដំបូងនៃការអភិវឌ្ឍន៍របស់ពួកគេ ក៏ដូចជាឧបករណ៍សម្រាប់ពួកគេដែរ ដូច្នេះនៅពេលរៀបចំសេណារីយ៉ូសាកល្បងស្មុគស្មាញ អ្នកនឹងត្រូវប្រឹងប្រែង។ ទោះជាយ៉ាងណាក៏ដោយគ្រាន់តែដាក់ពង្រាយជង់នៅក្នុងបរិយាកាសមួយ និងការធ្វើតេស្តនៅទីនោះគឺមានតម្លៃថោកមិនគួរឱ្យជឿ។ ហើយអ្នកមិនចាំបាច់ធ្វើច្បាប់ចម្លងមូលដ្ឋានពិតប្រាកដនៃបរិស្ថានពពកទេ។

ប្រើ AWS Lambda Layers ដើម្បីកាត់បន្ថយទំហំនៃកញ្ចប់ដែលបានដាក់ពង្រាយ និងបង្កើនល្បឿនការទាញយក។

ប្រើភាសាសរសេរកម្មវិធីត្រឹមត្រូវសម្រាប់កិច្ចការជាក់លាក់។ ភាសាផ្សេងៗគ្នាមានគុណសម្បត្តិ និងគុណវិបត្តិរៀងៗខ្លួន។ មានស្តង់ដារជាច្រើន ប៉ុន្តែ JavaScript, Python, និង C# (.NET Core 2.1+) គឺជាអ្នកដឹកនាំទាក់ទងនឹងការអនុវត្ត AWS Lambda។ ថ្មីៗនេះ AWS Lambda បានណែនាំ Runtime API ដែលអនុញ្ញាតឱ្យអ្នកបញ្ជាក់ភាសា និងបរិស្ថានពេលដំណើរការដែលអ្នកចង់បាន ដូច្នេះសាកល្បង។

រក្សាទំហំកញ្ចប់តូចសម្រាប់ដាក់ពង្រាយ។ ពួកវាកាន់តែតូច ការផ្ទុកកាន់តែលឿន។ ជៀសវាងការប្រើបណ្ណាល័យធំៗ ជាពិសេសប្រសិនបើអ្នកប្រើមុខងារមួយចំនួនពីពួកគេ។ ប្រសិនបើអ្នកកំពុងសរសេរកម្មវិធីនៅក្នុង JavaScript សូមប្រើឧបករណ៍បង្កើតដូចជា Webpack ដើម្បីបង្កើនប្រសិទ្ធភាពការស្ថាបនារបស់អ្នក ហើយរួមបញ្ចូលតែអ្វីដែលអ្នកពិតជាត្រូវការប៉ុណ្ណោះ។ .NET Core 3.0 មាន QuickJit និង Tiered Compilation ដែលធ្វើអោយដំណើរការប្រសើរឡើង និងជួយបានច្រើននៅពេលចាប់ផ្តើមត្រជាក់។

ការពឹងផ្អែកនៃមុខងារគ្មានម៉ាស៊ីនមេលើព្រឹត្តិការណ៍អាចធ្វើឱ្យវាពិបាកក្នុងការសំរបសំរួលតក្កវិជ្ជាអាជីវកម្មនៅពេលដំបូង។ ក្នុងន័យនេះ ជួរសារ និងម៉ាស៊ីនរដ្ឋអាចមានប្រយោជន៍មិនគួរឱ្យជឿ។ មុខងារ Lambda អាច​ហៅ​ទូរសព្ទ​ទៅ​គ្នា​បាន ប៉ុន្តែ​ធ្វើ​បាន​តែ​ប្រសិន​បើ​អ្នក​មិន​រំពឹង​ថា​នឹង​មាន​ការ​ឆ្លើយ​តប ("ភ្លើង​ហើយ​ភ្លេច") - អ្នក​មិន​ចង់​ទទួល​បាន​វិក្កយបត្រ​សម្រាប់​ការ​រង់ចាំ​មុខងារ​ផ្សេង​ទៀត​ដើម្បី​បញ្ចប់។ ជួរសារមានប្រយោជន៍សម្រាប់ការបែងចែកផ្នែកនៃតក្កវិជ្ជាអាជីវកម្ម ការគ្រប់គ្រងការរាំងស្ទះកម្មវិធី និងដំណើរការប្រតិបត្តិការ (ដោយប្រើជួរ FIFO)។ មុខងារ AWS Lambda អាចត្រូវបានកំណត់ទៅជួរ SQS ជាជួរសារដែលជាប់គាំង ដែលតាមដានសារដែលបរាជ័យសម្រាប់ការវិភាគនៅពេលក្រោយ។ មុខងារ​ជំហាន AWS (ម៉ាស៊ីន​រដ្ឋ) មាន​ប្រយោជន៍​ខ្លាំង​ណាស់​សម្រាប់​ការ​គ្រប់​គ្រង​ដំណើរ​ការ​ស្មុគ្រ​ស្មាញ​ដែល​តម្រូវ​ឱ្យ​មាន​មុខងារ​ច្រវាក់។ ជំនួសឱ្យមុខងារ Lambda ហៅមុខងារមួយផ្សេងទៀត មុខងារជំហានអាចសំរបសំរួលការផ្លាស់ប្តូររដ្ឋ បញ្ជូនទិន្នន័យរវាងមុខងារ និងគ្រប់គ្រងស្ថានភាពមុខងារសកល។ វាអនុញ្ញាតឱ្យអ្នកកំណត់លក្ខខណ្ឌនៃការព្យាយាមម្តងទៀត ឬអ្វីដែលត្រូវធ្វើនៅពេលដែលមានកំហុសជាក់លាក់មួយកើតឡើង - ឧបករណ៍ដ៏មានឥទ្ធិពលខ្លាំងនៅក្នុងលក្ខខណ្ឌជាក់លាក់។

សេចក្តីសន្និដ្ឋាន

ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ បច្ចេកវិទ្យាគ្មានម៉ាស៊ីនបម្រើត្រូវបានអភិវឌ្ឍក្នុងល្បឿនដែលមិនធ្លាប់មានពីមុនមក។ មាន​ការ​យល់​ខុស​មួយ​ចំនួន​ទាក់​ទង​នឹង​ការ​ផ្លាស់​ប្តូរ​គំរូ​នេះ។ តាមរយៈហេដ្ឋារចនាសម្ព័ន្ធអរូបី និងការគ្រប់គ្រងការធ្វើមាត្រដ្ឋាន ដំណោះស្រាយគ្មានម៉ាស៊ីនមេផ្តល់នូវអត្ថប្រយោជន៍យ៉ាងសំខាន់ ចាប់ពីការអភិវឌ្ឍន៍សាមញ្ញ និងដំណើរការ DevOps ដល់ការកាត់បន្ថយចំណាយប្រតិបត្តិការយ៉ាងច្រើន។
ខណៈពេលដែលវិធីសាស្រ្តគ្មានម៉ាស៊ីនមេគឺមិនមែនដោយគ្មានគុណវិបត្តិរបស់វានោះទេ មានគំរូរចនាដ៏រឹងមាំដែលអាចត្រូវបានប្រើដើម្បីបង្កើតកម្មវិធីគ្មានម៉ាស៊ីនមេដ៏រឹងមាំ ឬរួមបញ្ចូលធាតុគ្មានម៉ាស៊ីនមេទៅក្នុងស្ថាបត្យកម្មដែលមានស្រាប់។

ប្រភព: www.habr.com