5 ສິ່ງທ້າທາຍທີ່ຈະເຮັດໃຫ້ເມກຟັງ - ແລະຮູ້ວິທີແກ້ໄຂ

ພວກເຮົາ ກຳ ລັງ ດຳ ລົງຊີວິດຢູ່ໃນໂລກທີ່ມີເມກ. ທ່ານພຽງແຕ່ສາມາດອ່ານເວບໄຊທ໌ເຕັກໂນໂລຢີຫລືເຂົ້າໄປໃນກອງປະຊຸມໂດຍບໍ່ໄດ້ຍິນກ່ຽວກັບຜົນປະໂຫຍດທັງ ໝົດ ຂອງເຕັກໂນໂລຢີຫຼືສະຖາປັດຕະຍະ ກຳ ທີ່ໃຊ້ໃນເມຄເຊັ່ນ: ພາຊະນະ, microservices ແລະ ໜ້າ ທີ່ຂອງ server.

ເຖິງຢ່າງໃດກໍ່ຕາມທ່າມກາງຄວາມຕື່ນເຕັ້ນທັງ ໝົດ ກ່ຽວກັບການເກີດກັບເມຄ, ມັນສາມາດງ່າຍທີ່ຈະເບິ່ງຂ້າມສິ່ງທ້າທາຍທີ່ເກີດຂື້ນໃນເວລາທີ່ທ່ານຍ້າຍຈາກມໍລະດົກ, ການ ນຳ ໃຊ້ monolithic ໄປສູ່ຍຸດທະສາດທີ່ໃຊ້ໃນເມກ. ສິ່ງທ້າທາຍເຫຼົ່ານີ້ສາມາດເອົາຊະນະໄດ້, ແຕ່ວ່າຖ້າທ່ານແກ້ໄຂບັນຫາເຫຼົ່ານັ້ນເປັນສ່ວນ ໜຶ່ງ ຂອງຍຸດທະສາດການເຄື່ອນຍ້າຍຖິ່ນທີ່ມີເມຄຂອງທ່ານ.

ເພື່ອບັນລຸເປົ້າ ໝາຍ ດັ່ງກ່າວ, ຂໍໃຫ້ພິຈາລະນາຫ້າຂອງສິ່ງທ້າທາຍທົ່ວໄປທີ່ມີເມຄ, ພ້ອມກັບຍຸດທະສາດເພື່ອເອົາຊະນະພວກມັນ.

ເມກທີ່ໃຊ້ໃນເມກແມ່ນຫຍັງ?

ທຳ ອິດ, ຄຳ ທຳ ອິດກ່ຽວກັບ ຄຳ ວ່າເມກທີ່ມີຄວາມ ໝາຍ - ໝາຍ ເຖິງຕົວຈິງ.

ດ້ວຍ ຄຳ ເວົ້າທີ່ຢູ່ອ້ອມຮອບ 'ຟັງ', 'ຟັງ - ຖິ່ນ' ບາງຄັ້ງໃຊ້ໂດຍຄົນເພື່ອ ໝາຍ ເຖິງເຕັກໂນໂລຢີຫຼືກົນລະຍຸດໃດ ໜຶ່ງ ທີ່ພວກເຂົາຖືວ່າທັນສະ ໄໝ. ຈາກທັດສະນະດັ່ງກ່າວ, ຟັງແບບຟັງ - ສິ້ນສຸດລົງເປັນພຽງແຕ່ ຄຳ ສັບທີ່ບໍ່ມີຄວາມ ໝາຍ ອື່ນ.

ໃນທາງກົງກັນຂ້າມ, ເມື່ອລົງທືນດ້ວຍຄວາມ ໝາຍ ສະເພາະແລະ ຈຳ ກັດ, ຟັງ - ຟັງແມ່ນ ຄຳ ສັບແລະແນວຄິດທີ່ເປັນປະໂຫຍດ. ພວກເຮົາມັກ ຄຳ ນິຍາມຂອງ CNCF, ເຊິ່ງເນັ້ນ ໜັກ ເຖິງ“ ລະບົບການສົມທົບແບບວ່າງໆ” ແລະຄວາມຢືດຢຸ່ນຄືກັບລັກສະນະຂອງຄອມພິວເຕີ້ຟັງ. ຄຳ ນິຍາມຂອງ CNCF ຍັງຊີ້ໃຫ້ເຫັນບັນຊີລາຍຊື່ເຕັກໂນໂລຢີແລະສະຖາປັດຕະຍະ ກຳ ທີ່ສະເພາະແລະ ຈຳ ກັດ -“ ບັນຈຸ, ຕາ ໜ່າງ ການບໍລິການ, microservices, ໂຄງລ່າງພື້ນຖານທີ່ບໍ່ປ່ຽນແປງແລະ API ທີ່ປະກາດໃຊ້” - ເປັນຕົວຢ່າງຂອງເຕັກໂນໂລຢີທີ່ມີເມຄ.

ສຳ ລັບຈຸດປະສົງຂອງບົດຂຽນນີ້, ພວກເຮົາຈະຍຶດ ໝັ້ນ ກັບ ຄຳ ນິຍາມຂອງ CNCF ກ່ຽວກັບຄົນພື້ນເມືອງ. ຕອນນີ້, ໃຫ້ພວກເຮົາປຶກສາຫາລືກ່ຽວກັບສິ່ງທ້າທາຍສະເພາະທີ່ເກີດຂື້ນໃນເວລາທີ່ທ່ານ ນຳ ໃຊ້ເຕັກໂນໂລຢີແລະກົນລະຍຸດຄືກັບທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

ສິ່ງທ້າທາຍໃນການຮັບຮອງເອົາ Cloud Native

1) ການເກັບຂໍ້ມູນທີ່ທົນທານ

ສິ່ງທ້າທາຍທົ່ວໄປ ໜຶ່ງ ທີ່ມີຫຼາຍເຕັກໂນໂລຢີທີ່ໃຊ້ໃນເມຄແມ່ນການເກັບຂໍ້ມູນຢ່າງຕໍ່ເນື່ອງ. ພາຊະນະບັນຈຸ, ໜ້າ ທີ່ແລະ server ທີ່ຖືກ ນຳ ໃຊ້ໂດຍໃຊ້ຮູບແບບໂຄງລ່າງພື້ນຖານທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້ໂດຍປົກກະຕິບໍ່ມີວິທີການເກັບຂໍ້ມູນພາຍໃນຕົວເອງຢ່າງຖາວອນເພາະວ່າຂໍ້ມູນພາຍໃນທັງ ໝົດ ຖືກ ທຳ ລາຍໃນເວລາທີ່ແອັບພລິເຄຊັນຖືກປິດລົງ.

ການແກ້ໄຂສິ່ງທ້າທາຍນີ້ຮຽກຮ້ອງໃຫ້ຄິດຄືນ ໃໝ່ ວິທີການໃນການເກັບຂໍ້ມູນໂດຍການປ່ຽນຮູບແບບຈາກການ ນຳ ໃຊ້ແລະສະພາບແວດລ້ອມຂອງເຈົ້າພາບ. ແທນທີ່ຈະເກັບຮັກສາຂໍ້ມູນພາຍໃນສະພາບແວດລ້ອມຂອງການ ນຳ ໃຊ້, ໂປແກມເຮັດວຽກແບບຟັງໄດ້ເກັບຮັກສາມັນໄວ້ພາຍນອກແລະເປີດເຜີຍຂໍ້ມູນໃຫ້ເປັນບໍລິການ. ຈາກນັ້ນ, ວຽກທີ່ຕ້ອງການເຂົ້າເຖິງຂໍ້ມູນ, ເຊື່ອມຕໍ່ກັບມັນຄືກັນກັບວ່າພວກເຂົາຈະເຊື່ອມຕໍ່ກັບບໍລິການອື່ນໆ.

ວິທີການນີ້ - ເຊິ່ງເປີດໃຊ້ໂດຍເຄື່ອງມືຕ່າງໆ, ເຊັ່ນ: ບໍລິມາດໃນ Kubernetes - ມີປະໂຫຍດສອງຢ່າງ. ນອກ ເໜືອ ຈາກການເຮັດໃຫ້ການເກັບຂໍ້ມູນແບບຍືນຍົງ ສຳ ລັບແອັບພລິເຄຊັນທີ່ບໍ່ໄດ້ຖືກອອກແບບມາເພື່ອໃຫ້ມີຄວາມທົນທານ, ມັນຍັງເຮັດໃຫ້ມັນງ່າຍທີ່ຈະແບ່ງປັນສະລອຍນ້ ຳ ເກັບຂໍ້ມູນແບບດຽວໃນບັນດາໂປແກຼມຫລືບໍລິການທີ່ຫຼາກຫຼາຍ.

2) ການເຊື່ອມໂຍງການບໍລິການ

ແອັບພລິເຄຊັນພື້ນເມືອງໃນທ້ອງຖິ່ນແມ່ນປະກອບດ້ວຍການບໍລິການທີ່ແຕກຕ່າງກັນ. ທຳ ມະຊາດທີ່ແຈກຢາຍນີ້ແມ່ນສິ່ງທີ່ຊ່ວຍເຮັດໃຫ້ພວກເຂົາສາມາດປັບຂະ ໜາດ ແລະປ່ຽນແປງໄດ້, ທຽບກັບ monoliths.

ແຕ່ມັນຍັງ ໝາຍ ຄວາມວ່າວຽກງານທີ່ມີຢູ່ໃນເມຄມີຫຼາຍຕ່ອນເຄື່ອນຍ້າຍທີ່ຕ້ອງໄດ້ເຊື່ອມໂຍງເຂົ້າກັນຢ່າງ ແໜ້ນ ແຟ້ນເພື່ອໃຫ້ປະສົບຜົນ ສຳ ເລັດ.

ສ່ວນ ໜຶ່ງ, ການລວມເອົາການບໍລິການແມ່ນບັນຫາ ໜຶ່ງ ສຳ ລັບນັກພັດທະນາໃນການແກ້ໄຂຍ້ອນວ່າພວກເຂົາສ້າງແອັບ-ທີ່ມີເມຄ. ພວກເຂົາຕ້ອງຮັບປະກັນວ່າແຕ່ລະການບໍລິການມີຂະ ໜາດ ທີ່ ເໝາະ ສົມ; ການປະຕິບັດທີ່ດີທີ່ສຸດແມ່ນການສ້າງການບໍລິການທີ່ແຕກຕ່າງກັນ ສຳ ລັບແຕ່ລະປະເພດຂອງ ໜ້າ ທີ່ພາຍໃນເວລາເຮັດວຽກ, ແທນທີ່ຈະພະຍາຍາມເຮັດໃຫ້ການບໍລິການດຽວເຮັດຫຼາຍສິ່ງ. ມັນຍັງມີຄວາມ ສຳ ຄັນທີ່ຈະຫລີກລ້ຽງການເພີ່ມບໍລິການພຽງແຕ່ທ່ານສາມາດ. ກ່ອນທີ່ທ່ານຈະແນະ ນຳ ຄວາມສັບສົນເພີ່ມເຕີມໃຫ້ກັບແອັບ your ຂອງທ່ານໃນຮູບແບບຂອງການບໍລິການອື່ນ, ໃຫ້ແນ່ໃຈວ່າການບໍລິການກ້າວໄປສູ່ຈຸດປະສົງສະເພາະໃດ ໜຶ່ງ.

ນອກ ເໜືອ ຈາກສະຖາປັດຕະຍະ ກຳ ຂອງແອັບພລິເຄຊັນເອງ, ການລວມຕົວການບໍລິການທີ່ມີປະສິດຕິຜົນຍັງຂຶ້ນກັບການເລືອກເຕັກນິກການ ນຳ ໃຊ້ທີ່ຖືກຕ້ອງ. ພາຊະນະອາດຈະເປັນວິທີທີ່ຈະແຈ້ງທີ່ສຸດໃນການ ນຳ ໃຊ້ຫລາຍບໍລິການແລະເຮັດໃຫ້ພວກເຂົາເຂົ້າໄປໃນວຽກງານດຽວ, ແຕ່ໃນບາງກໍລະນີ, ໜ້າ ທີ່ທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍຫລືແອັບ apps ທີ່ບໍ່ໄດ້ບັນຈຸເຊື່ອມຕໍ່ໂດຍ API ອາດຈະເປັນວິທີການຈັດການບໍລິການທີ່ດີກວ່າເກົ່າ.

3) ການຄຸ້ມຄອງແລະຕິດຕາມ

ການບໍລິການຫຼາຍເທົ່າໃດທີ່ທ່ານ ດຳ ເນີນການເປັນສ່ວນ ໜຶ່ງ ຂອງແອັບພລິເຄຊັນ, ມັນຍາກທີ່ຈະຕິດຕາມແລະຈັດການກັບພວກມັນ. ນີ້ແມ່ນຄວາມຈິງ, ຍ້ອນບໍ່ພຽງແຕ່ ຈຳ ນວນການບໍລິການທີ່ທ່ານຕ້ອງຕິດຕາມເທົ່ານັ້ນ, ແຕ່ຍ້ອນວ່າການຮັບປະກັນສຸຂະພາບໃນການສະ ໝັກ ຕ້ອງການຕິດຕາມຄວາມ ສຳ ພັນລະຫວ່າງການບໍລິການ, ບໍ່ພຽງແຕ່ໃຫ້ບໍລິການຕົວເອງເທົ່ານັ້ນ.

ການຕິດຕາມແລະຄຸ້ມຄອງບໍລິການຢ່າງມີປະສິດຕິຜົນໃນສະພາບແວດລ້ອມທີ່ມີເມຄ, ດັ່ງນັ້ນ, ຈຶ່ງຮຽກຮ້ອງໃຫ້ມີວິທີການທີ່ສາມາດຄາດເດົາໄດ້ວ່າຄວາມລົ້ມເຫຼວຂອງການບໍລິການ ໜຶ່ງ ຈະສົ່ງຜົນກະທົບຕໍ່ຄົນອື່ນແນວໃດ, ພ້ອມທັງເຂົ້າໃຈວ່າຄວາມລົ້ມເຫຼວໃດແມ່ນ ສຳ ຄັນທີ່ສຸດ. ຊັ້ນໃຕ້ດິນແບບເຄື່ອນໄຫວ, ຊຶ່ງ ໝາຍ ເຖິງການປ່ຽນພື້ນທີ່ແບບຄົງທີ່ກັບສິ່ງທີ່ປະເມີນສະພາບແວດລ້ອມໃນການ ນຳ ໃຊ້ຢ່າງຕໍ່ເນື່ອງເພື່ອ ກຳ ນົດສິ່ງທີ່ເປັນ ທຳ ມະດາແລະສິ່ງທີ່ຜິດປົກກະຕິ, ກໍ່ມີຄວາມ ສຳ ຄັນເຊັ່ນກັນ.

4) ຫລີກລ້ຽງການລັອກໃນເມກ

ຄວາມສ່ຽງ Lock-in ບໍ່ແມ່ນເອກະລັກກັບເມຄ; ພວກມັນສາມາດເກີດຂື້ນຈາກເຕັກໂນໂລຢີເກືອບທຸກປະເພດ, ແລະພວກມັນໄດ້ເປັນໄພຂົ່ມຂູ່ຕໍ່ຄວາມແຂງຂັນໃນຫລາຍທົດສະວັດ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ໃນກໍລະນີຂອງການ ນຳ ໃຊ້ເມຄຫລືສະຖາປັດຕະຍະ ກຳ, ການຂົ່ມຂູ່ທີ່ຈະຂື້ນກັບຜູ້ໃຫ້ບໍລິການຟັງຫຼືການບໍລິການຟັງໂດຍສະເພາະແມ່ນສາມາດເປັນສິ່ງທີ່ຍິ່ງໃຫຍ່ໂດຍສະເພາະເນື່ອງຈາກຄວາມງ່າຍດາຍຂອງການ ນຳ ໃຊ້ວຽກທີ່ສາມາດ ນຳ ໃຊ້ໄດ້ໃນແບບທີ່ພວກເຂົາຮຽກຮ້ອງໃຫ້ມີສະເພາະ ບໍລິການຈາກເມຄໂດຍສະເພາະ.

ໂຊກດີ, ການຫຼຸດຜ່ອນຄວາມສ່ຽງໃນການລັອກຟັງນີ້ແມ່ນງ່າຍພຽງພໍເທົ່າທີ່ທ່ານວາງແຜນໄວ້ກ່ອນ. ການຍຶດ ໝັ້ນ ກັບມາດຕະຖານຂອງຊຸມຊົນ (ຄືກັບທີ່ໄດ້ຮັບການສົ່ງເສີມໂດຍ OCCI) ຈະເຮັດໄດ້ຫຼາຍຢ່າງເພື່ອຮັບປະກັນວ່າທ່ານສາມາດຍ້າຍວຽກຂອງທ່ານໄດ້ຢ່າງງ່າຍດາຍຈາກຟັງ ໜຶ່ງ ໄປອີກ. ເຊັ່ນດຽວກັນ, ໃນຂະນະທີ່ທ່ານວາງແຜນວ່າການບໍລິການຟັງໃດທີ່ທ່ານຈະໃຊ້ໃນການຟັງ - ຟັງ, ພິຈາລະນາວ່າບໍລິການໃດ ໜຶ່ງ ທີ່ທ່ານ ກຳ ລັງພິຈາລະນາມີຄຸນລັກສະນະທີ່ເປັນເອກະລັກແທ້ໆແລະບໍ່ສາມາດໃຊ້ໄດ້ຈາກເມຄອື່ນໆ. ຖ້າພວກເຂົາເຮັດ, ຫລີກລ້ຽງຄຸນລັກສະນະເຫຼົ່ານັ້ນ, ເພາະວ່າພວກເຂົາສາມາດລັອກທ່ານ.

ຍົກຕົວຢ່າງ, ພາສາແລະກອບສະເພາະທີ່ໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຈາກເວທີຄອມພິວເຕີ້ເຊີຟເວີຂອງເມຄສາທາລະນະຕ່າງໆແຕກຕ່າງກັນບາງຢ່າງ. ຕົວຢ່າງ AWS Lambda ສະ ໜັບ ສະ ໜູນ Go, ແຕ່ Azure ບໍ່ໄດ້. ດ້ວຍເຫດຜົນນັ້ນ, ທ່ານຄວນສະຫລາດທີ່ຈະຫລີກລ້ຽງການຂຽນ ໜ້າ ທີ່ທີ່ທ່ານບໍ່ສາມາດຂຽນລົງໃນ Go. ເຖິງແມ່ນວ່າທ່ານວາງແຜນທີ່ຈະໃຊ້ AWS ເພື່ອເປັນເຈົ້າພາບໃຫ້ພວກເຂົາໃນເບື້ອງຕົ້ນ, ການເພິ່ງພາອາໄສນີ້ຈະເຮັດໃຫ້ມັນຍາກທີ່ຈະຍ້າຍໄປສູ່ເມຄອື່ນໃນອະນາຄົດ. ຕິດກັບພາສາເຊັ່ນ Java, ເຊິ່ງທ່ານສາມາດວາງເດີມພັນໄດ້ຢ່າງປອດໄພຈະໄດ້ຮັບການສະ ໜັບ ສະ ໜູນ ຢູ່ທຸກບ່ອນ.

5) ສ້າງແອັບພລິເຄຊັນສົ່ງທໍ່ເມກແບບດັ້ງເດີມ

ຕາມ ຄຳ ນິຍາມ, ແອັບ-ທີ່ມີຖິ່ນ ກຳ ເນີດໃນກຸ່ມຟັງ. ໃນຂະນະທີ່ເມຄສາມາດເປັນຟັງສາທາລະນະ, ຫຼືສ່ວນຕົວ, ໃນລະດັບສະພາບແວດລ້ອມຂອງອົງກອນຂອງທ່ານ - ມັນ ໝາຍ ຄວາມວ່າພື້ນຖານໂຄງລ່າງທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້ແລະຂັ້ນຕອນການຄຸ້ມຄອງເມຄ. ແຕ່ທໍ່ສົ່ງເຄື່ອງສະ ໝັກ ຫຼາຍໆບ່ອນຍັງໃຊ້ໄດ້ສ່ວນໃຫຍ່ໃນສະພາບແວດລ້ອມໃນສະຖານທີ່ທີ່ເປັນປະເພນີທີ່ອາດຈະບໍ່ມີເມຄຫລືຄຶກຄັກເມື່ອປະສົມປະສານກັບແອັບພລິເຄຊັນແລະບໍລິການທີ່ແລ່ນຢູ່ໃນເມຄສາທາລະນະຫລືໃນພາຊະນະ.

ນີ້ສ້າງສິ່ງທ້າທາຍໃນຫລາຍດ້ານ. ໜຶ່ງ ແມ່ນວ່າການ ນຳ ໃຊ້ລະຫັດຈາກສະພາບແວດລ້ອມໃນທ້ອງຖິ່ນມາສູ່ສະຖານທີ່ໃນສະຖານທີ່ສາມາດແນະ ນຳ ໃຫ້ມີຄວາມລ່າຊ້າ. ອີກອັນ ໜຶ່ງ ແມ່ນການພັດທະນາແລະທົດລອງໃນທ້ອງຖິ່ນເຮັດໃຫ້ມັນຍາກທີ່ຈະເຮັດຕາມສະພາບການຜະລິດ, ເຊິ່ງສາມາດ ນຳ ໄປສູ່ພຶດຕິ ກຳ ການສະ ໝັກ ທີ່ບໍ່ໄດ້ຄາດຫວັງ, ການຈັດສົ່ງຫລັງ.

ວິທີທີ່ມີປະສິດທິຜົນທີ່ສຸດໃນການເອົາຊະນະອຸປະສັກເຫຼົ່ານີ້ແມ່ນການຍ້າຍທໍ່ CI / CD ຂອງທ່ານໄປສູ່ສະພາບແວດລ້ອມໃນເມຄ - ບໍ່ພຽງແຕ່ໄດ້ຮັບຜົນປະໂຫຍດຈາກພື້ນຖານໂຄງລ່າງທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້ແລະຄວາມສາມາດຂະຫຍາຍໄດ້ຂອງເມຄແລະຜົນປະໂຫຍດອື່ນໆ, ແຕ່ຍັງເຮັດໃຫ້ເກີດສະພາບການຜະລິດແລະ ນຳ ເອົາທໍ່ຂອງທ່ານເຂົ້າໃກ້ - ຫຼາຍ ເປັນໄປໄດ້ - ສຳ ລັບແອັບ your ຂອງທ່ານ. ວິທີນັ້ນ, ລະຫັດຖືກຂຽນຂື້ນໃກ້ກັບບ່ອນທີ່ມັນຖືກ ນຳ ໃຊ້, ເຮັດໃຫ້ການ ນຳ ໃຊ້ໄວຂື້ນ. ມັນຍັງກາຍເປັນສະພາບແວດລ້ອມການທົດສອບທີ່ງ່າຍຂື້ນກັບສະພາບແວດລ້ອມການຜະລິດ.

ໃນຂະນະທີ່ການພັດທະນາທີ່ມີເມຄຢ່າງສົມບູນບໍ່ແມ່ນ ສຳ ລັບທຸກໆຄົນແລະນັກພັດທະນາບາງຄົນມັກຄວາມຄຸ້ນເຄີຍແລະຄວາມຕອບສະ ໜອງ ຂອງ IDE ທ້ອງຖິ່ນໃນໄລຍະທີ່ໃຊ້ເມຄ, ພະຍາຍາມຮັບປະກັນທໍ່ CI / CD ຂອງທ່ານ ກຳ ລັງແລ່ນຢູ່ໃນສະພາບແວດລ້ອມຂອງເມຄ, ໃນຂອບເຂດທີ່ເປັນໄປໄດ້.

ສະຫຼຸບ

ບໍ່ວ່າທ່ານຈະ ໝຸນ ມັນ, ການໄປຟັງແບບຟັງກໍ່ຍາກ. ເມື່ອປຽບທຽບກັບ ຄຳ ຮ້ອງສະ ໝັກ ທີ່ເປັນມໍລະດົກ, ແອັບພລິເຄຊັນທີ່ໃຊ້ໃນເມກມີຄວາມສັບສົນຫຼາຍແລະມີສະຖານທີ່ຫຼາຍບ່ອນທີ່ມີສິ່ງທີ່ຜິດພາດ. ທີ່ເວົ້າວ່າ, ສິ່ງທ້າທາຍດ້ານຄອມພິວເຕີ້ແບບ cloud ສາມາດເອົາຊະນະໄດ້ - ແລະການປະຕິບັດຍຸດທະສາດທີ່ສາມາດແກ້ໄຂບັນດາສິ່ງທ້າທາຍແມ່ນກຸນແຈ ສຳ ຄັນໃນການປົດລັອກຄວາມຄ່ອງແຄ້ວ, ຄວາມ ໜ້າ ເຊື່ອຖືແລະຄວາມສາມາດປັບຂະຫຍາຍໄດ້ເຊິ່ງພຽງແຕ່ສະຖາປັດຕະຍະ ກຳ ພື້ນເມືອງຂອງເມຄທີ່ສາມາດສົ່ງມອບໄດ້.