ចំណុច​សំខាន់

• អស់ជាច្រើនឆ្នាំមកនេះ យើងត្រូវបានគេសន្យាថា កុំព្យូទ័រគ្មានម៉ាស៊ីនមេនឹងឈានទៅរកយុគសម័យថ្មីដោយគ្មានប្រព័ន្ធប្រតិបត្តិការជាក់លាក់ដើម្បីដំណើរការកម្មវិធី។ យើងត្រូវបានគេប្រាប់ថារចនាសម្ព័ន្ធនេះនឹងដោះស្រាយបញ្ហាលទ្ធភាពធ្វើមាត្រដ្ឋានជាច្រើន។ តាមពិតអ្វីៗគឺខុសគ្នា។
• ខណៈពេលដែលមនុស្សជាច្រើនចាត់ទុក serverless ជាគំនិតថ្មី ឫសរបស់វាអាចត្រូវបានតាមដានត្រលប់ទៅឆ្នាំ 2006 ជាមួយនឹងវត្តមានរបស់ Zimki PaaS និង Google App Engine ដែលទាំងពីរប្រើស្ថាបត្យកម្ម serverless ។
• មានហេតុផលបួនយ៉ាងដែលបដិវត្តន៍គ្មានម៉ាស៊ីនមេបានជាប់គាំង រាប់ចាប់ពីការគាំទ្រភាសាសរសេរកម្មវិធីមានកម្រិត រហូតដល់បញ្ហាដំណើរការ។
• កុំព្យូទ័រគ្មានម៉ាស៊ីនមេ មិនមែនសុទ្ធតែគ្មានប្រយោជន៍នោះទេ។ មិនមែនទាល់តែសោះ។ ទោះយ៉ាងណាក៏ដោយ ពួកគេមិនគួរត្រូវបានចាត់ទុកថាជាការជំនួសដោយផ្ទាល់សម្រាប់ម៉ាស៊ីនមេទេ។ សម្រាប់កម្មវិធីមួយចំនួន ពួកគេអាចជាឧបករណ៍ងាយស្រួល។

server ងាប់ហើយ អោយ server រស់បានយូរ!

នេះ​ជា​ការ​ប្រយុទ្ធ​គ្នា​នៃ​បដិវត្តន៍​គ្មាន​ម៉ាស៊ីន​បម្រើ។ គ្រាន់តែក្រឡេកមើលសារព័ត៌មានឧស្សាហកម្មក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ ហើយវាងាយស្រួលក្នុងការសន្និដ្ឋានថាគំរូម៉ាស៊ីនមេប្រពៃណីបានស្លាប់ ហើយក្នុងរយៈពេលពីរបីឆ្នាំទៀត យើងទាំងអស់គ្នានឹងប្រើប្រាស់ស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេ។

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

ការសន្យាមួយចំនួននៃម៉ូដែលគ្មានម៉ាស៊ីនមេ ប្រាកដជាត្រូវបានសម្រេច ប៉ុន្តែមិនមែនទាំងអស់នោះទេ។ មិន​មែន​គ្រប់​គ្នា។

នៅក្នុងអត្ថបទនេះខ្ញុំចង់ពិនិត្យមើលមូលហេតុនៃស្ថានភាពនេះ។ ហេតុអ្វីបានជាការខ្វះខាតនៃភាពបត់បែននៃម៉ូដែលគ្មានម៉ាស៊ីនមេនៅតែជាឧបសគ្គដល់ការទទួលយកកាន់តែទូលំទូលាយរបស់ពួកគេ ទោះបីជាវានៅតែមានប្រយោជន៍ក្នុងកាលៈទេសៈជាក់លាក់ និងច្បាស់លាស់ក៏ដោយ។

អ្វីដែលអ្នកជំនាញនៃកុំព្យូទ័រគ្មានម៉ាស៊ីនមេបានសន្យា

មុនពេលយើងចូលទៅក្នុងបញ្ហាប្រឈមនៃកុំព្យូទ័រគ្មានម៉ាស៊ីនមេ សូមក្រឡេកមើលអ្វីដែលវាត្រូវបានគេសន្មត់ថាផ្តល់ឱ្យ។ ការសន្យានៃបដិវត្តន៍គ្មានម៉ាស៊ីនបម្រើ មានច្រើនហើយ - ពេលខ្លះ - មានមហិច្ឆតាខ្លាំងណាស់។

សម្រាប់​អ្នក​ដែល​មិន​ស្គាល់​ពាក្យ នេះ​ជា​និយមន័យ​រហ័ស។ កុំព្យូទ័រគ្មានម៉ាស៊ីនមេកំណត់ស្ថាបត្យកម្មដែលកម្មវិធី (ឬផ្នែកនៃកម្មវិធី) ដំណើរការតាមតម្រូវការក្នុងបរិយាកាសដំណើរការដែលជាធម្មតាត្រូវបានបង្ហោះពីចម្ងាយ។ លើសពីនេះ ប្រព័ន្ធ serverless អាចត្រូវបានបង្ហោះនៅផ្ទះ។ ការកសាងប្រព័ន្ធ serverless ដែលធន់ទ្រាំនឹងការបារម្ភជាចម្បងសម្រាប់អ្នកគ្រប់គ្រងប្រព័ន្ធ និងក្រុមហ៊ុន SaaS ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ ដោយសារ (វាត្រូវបានអះអាង) ស្ថាបត្យកម្មនេះផ្តល់នូវអត្ថប្រយោជន៍សំខាន់ៗជាច្រើនលើគំរូម៉ាស៊ីនបម្រើអតិថិជន "ប្រពៃណី"៖

1. ម៉ូដែលគ្មានម៉ាស៊ីនមេ មិនតម្រូវឱ្យអ្នកប្រើប្រាស់រក្សាប្រព័ន្ធប្រតិបត្តិការផ្ទាល់ខ្លួនរបស់ពួកគេ ឬសូម្បីតែបង្កើតកម្មវិធីដែលត្រូវគ្នាជាមួយប្រព័ន្ធប្រតិបត្តិការជាក់លាក់។ ផ្ទុយទៅវិញ អ្នកអភិវឌ្ឍន៍បង្កើតកូដចែករំលែក បង្ហោះវាទៅក្នុងវេទិកាគ្មានម៉ាស៊ីនមេ ហើយមើលវាដំណើរការ។
2. ធនធាននៅក្នុងក្របខណ្ឌដែលគ្មានម៉ាស៊ីនមេ ជាធម្មតាត្រូវបានគិតត្រឹមនាទី (ឬសូម្បីតែទីពីរ)។ នេះ​មាន​ន័យ​ថា​អតិថិជន​ចំណាយ​តែ​សម្រាប់​ពេល​ដែល​ពួកគេ​ដំណើរការ​កូដ​ពិត​ប្រាកដ​ប៉ុណ្ណោះ។ នេះប្រៀបធៀបល្អជាមួយ cloud VM ប្រពៃណី ដែលម៉ាស៊ីននៅទំនេរភាគច្រើន ប៉ុន្តែអ្នកត្រូវចំណាយសម្រាប់វា។
3. បញ្ហានៃការធ្វើមាត្រដ្ឋានក៏ត្រូវបានដោះស្រាយផងដែរ។ ធនធាននៅក្នុងក្របខណ្ឌដែលមិនមានម៉ាស៊ីនមេត្រូវបានចាត់ចែងជាលក្ខណៈថាមវន្ត ដូច្នេះប្រព័ន្ធអាចដោះស្រាយបានយ៉ាងងាយស្រួលជាមួយនឹងការកើនឡើងភ្លាមៗនៃតម្រូវការ។

សរុបមក ម៉ូដែលគ្មានម៉ាស៊ីនបម្រើផ្តល់នូវដំណោះស្រាយដែលអាចបត់បែនបាន តម្លៃទាប និងអាចធ្វើមាត្រដ្ឋានបាន។ វាគួរឱ្យភ្ញាក់ផ្អើលដែលយើងមិនបានគិតពីគំនិតនេះឆាប់ជាងនេះ។

តើនេះពិតជាគំនិតថ្មីមែនទេ?

តាម​ពិត គំនិត​មិន​មែន​ជា​រឿង​ថ្មី​ទេ។ គោលគំនិតនៃការអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់បង់ប្រាក់សម្រាប់តែពេលវេលាដែលលេខកូដកំពុងដំណើរការពិតប្រាកដគឺបានកើតឡើងចាប់តាំងពីវាត្រូវបានណែនាំដោយ Zimki PaaS ក្នុងឆ្នាំ 2006 ហើយនៅពេលដូចគ្នានេះ Google App Engine បានផ្តល់ដំណោះស្រាយស្រដៀងគ្នា។

តាមពិតទៅ អ្វី​ដែល​យើង​ហៅ​ថា​ម៉ូដែល "serverless" គឺ​ចាស់​ជាង​បច្ចេកវិទ្យា​ជាច្រើន​ដែល​ឥឡូវ​គេ​ហៅថា "cloud native" ដែល​ផ្តល់​នូវ​អ្វី​ដូចគ្នា​ច្រើន។ ដូចដែលបានកត់សម្គាល់ ម៉ូដែលគ្មានម៉ាស៊ីនមេគឺគ្រាន់តែជាផ្នែកបន្ថែមនៃគំរូអាជីវកម្ម SaaS ដែលមានរយៈពេលជាច្រើនទសវត្សរ៍មកហើយ។

វាក៏មានតម្លៃផងដែរក្នុងការទទួលស្គាល់ថា serverless មិនមែនជាស្ថាបត្យកម្ម FaaS ទេ ទោះបីជាមានការតភ្ជាប់រវាងទាំងពីរក៏ដោយ។ FaaS គឺជាផ្នែកសំខាន់នៃការគណនានៃស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេ ប៉ុន្តែវាមិនតំណាងឱ្យប្រព័ន្ធទាំងមូលនោះទេ។

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

បញ្ហាជាមួយម៉ូដែលគ្មានម៉ាស៊ីនមេ

ចាប់បានគឺថា ម៉ូដែលគ្មានម៉ាស៊ីនមេមានបញ្ហា... កុំយល់ច្រឡំ៖ ខ្ញុំមិននិយាយថាពួកគេអាក្រក់ក្នុងមួយ se ឬមិនផ្តល់តម្លៃសំខាន់ដល់ក្រុមហ៊ុនមួយចំនួនក្នុងកាលៈទេសៈមួយចំនួន។ ប៉ុន្តែការអះអាងចម្បងនៃ "បដិវត្តន៍" - ស្ថាបត្យកម្មដែលគ្មានម៉ាស៊ីនមេនឹងជំនួសស្ថាបត្យកម្មប្រពៃណីយ៉ាងឆាប់រហ័ស - មិនដែលក្លាយជាការពិតទេ។

នោះ​ហើយ​ជា​មូល​ហេតុ​ដែល។

ការគាំទ្រមានកម្រិតសម្រាប់ភាសាសរសេរកម្មវិធី

វេទិកាគ្មានម៉ាស៊ីនមេភាគច្រើនអនុញ្ញាតឱ្យអ្នកដំណើរការកម្មវិធីដែលត្រូវបានសរសេរជាភាសាជាក់លាក់ប៉ុណ្ណោះ។ នេះកំណត់យ៉ាងធ្ងន់ធ្ងរទៅលើភាពបត់បែន និងការសម្របសម្រួលនៃប្រព័ន្ធទាំងនេះ។

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

នេះធ្វើឱ្យខូចប្រយោជន៍សំខាន់មួយនៃគំរូម៉ាស៊ីនមេ។

ការចងអ្នកលក់

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

ផ្នែកដ៏លំបាកបំផុតនៃការផ្លាស់ប្តូរទៅម៉ូដែលគ្មានម៉ាស៊ីនមេ មិនមែនជាមុខងារគណនា ដែលជាធម្មតាគ្រាន់តែជាផ្នែកតូចៗនៃកូដប៉ុណ្ណោះ ប៉ុន្តែរបៀបដែលកម្មវិធីទាក់ទងជាមួយប្រព័ន្ធដែលបានតភ្ជាប់ ដូចជាការផ្ទុកវត្ថុ ការគ្រប់គ្រងអត្តសញ្ញាណ និងជួរ។ មុខងារអាចត្រូវបានផ្លាស់ទី ប៉ុន្តែកម្មវិធីដែលនៅសល់មិនអាចទេ។ នេះគឺជាការផ្ទុយគ្នាពិតប្រាកដនៃវេទិកាដែលមានតំលៃថោក និងអាចបត់បែនបានដែលត្រូវបានសន្យា។

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

ផលិតភាព

ដំណើរការកុំព្យូទ័រនៃវេទិកាគ្មានម៉ាស៊ីនមេគឺពិបាកក្នុងការវាស់វែងមួយផ្នែក ដោយសារតែអ្នកលក់មានទំនោររក្សាព័ត៌មានជាឯកជន។ ភាគច្រើនប្រកែកថាមុខងារនៅលើវេទិកាគ្មានម៉ាស៊ីនមេពីចម្ងាយ ដំណើរការលឿនដូចម៉ាស៊ីនមេខាងក្នុង លើកលែងតែបញ្ហា latency ដែលជៀសមិនរួចមួយចំនួន។

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

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

វិធីសាស្រ្តមួយផ្សេងទៀតគឺដើម្បីធានាថាកម្មវិធីសំខាន់ដែលផលិតភាពត្រូវបានដំណើរការជាទៀងទាត់ដើម្បីរក្សាវាឱ្យស្រស់។ វិធីសាស្រ្តទីពីរនេះជាការពិតណាស់ មានភាពផ្ទុយគ្នាបន្តិចទៅនឹងការអះអាងដែលថា វេទិកាគ្មានម៉ាស៊ីនមេ មានប្រសិទ្ធភាពជាង ដោយសារអ្នកចំណាយត្រឹមតែពេលវេលាដែលកម្មវិធីរបស់អ្នកកំពុងដំណើរការប៉ុណ្ណោះ។ អ្នកផ្តល់សេវាពពកបានណែនាំវិធីថ្មីដើម្បីកាត់បន្ថយការចាប់ផ្តើមត្រជាក់ ប៉ុន្តែពួកគេជាច្រើនទាមទារ "មាត្រដ្ឋានមួយ" ដែលបំផ្លាញតម្លៃដើមរបស់ FaaS ។

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

អ្នកមិនអាចដំណើរការកម្មវិធីទាំងមូលបានទេ។

ទីបំផុត ប្រហែលជាហេតុផលដ៏សំខាន់បំផុតដែលស្ថាបត្យកម្មគ្មានម៉ាស៊ីនមេនឹងមិនជំនួសគំរូប្រពៃណីគ្រប់ពេលទេ៖ ពួកគេ (ជាធម្មតា) មិនអាចដំណើរការកម្មវិធីទាំងមូលបានទេ។

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

នេះមានន័យថានៅក្នុងករណីភាគច្រើន វេទិកាគ្មានម៉ាស៊ីនមេត្រូវបានប្រើជាការបំពេញបន្ថែមទៅម៉ាស៊ីនមេខាងក្រោយ ដើម្បីអនុវត្តកិច្ចការដែលពឹងផ្អែកលើកុំព្យូទ័រ។ នេះធ្វើឱ្យពួកវាមានភាពខុសប្លែកគ្នាយ៉ាងខ្លាំងពីទម្រង់ពីរផ្សេងទៀតនៃបច្ចេកវិទ្យាពពក - កុងតឺន័រ និងម៉ាស៊ីននិម្មិត - ដែលផ្តល់នូវវិធីរួមមួយដើម្បីដំណើរការកុំព្យូទ័រពីចម្ងាយ។ នេះបង្ហាញពីបញ្ហាប្រឈមមួយនៃការផ្លាស់ប្តូរពី microservices ទៅ serverless ។

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

រស់រានមានជីវិតយូរ បដិវត្តន៍?

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

ប្រភព: www.habr.com