ຄໍາແນະນໍາແລະຊັບພະຍາກອນສໍາລັບການກໍ່ສ້າງແອັບພລິເຄຊັນທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ

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

ຄວາມເຂົ້າໃຈຜິດກ່ຽວກັບເຕັກໂນໂລຊີ Serverless

ຫຼາຍຄົນຄິດວ່າການປະມວນຜົນ serverless ແລະ serverless (ຫນ້າທີ່ເປັນບໍລິການ, FaaS) ແມ່ນເກືອບຄືກັນ. ນີ້ຫມາຍຄວາມວ່າຄວາມແຕກຕ່າງບໍ່ໃຫຍ່ເກີນໄປແລະມັນຄຸ້ມຄ່າທີ່ຈະແນະນໍາຄວາມແປກໃຫມ່. ເຖິງແມ່ນວ່າ AWS Lambda ເປັນຫນຶ່ງໃນດາວຂອງຍຸກທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍແລະເປັນຫນຶ່ງໃນອົງປະກອບທີ່ນິຍົມທີ່ສຸດຂອງສະຖາປັດຕະຍະກໍາ serverless, ຢ່າງໃດກໍຕາມ, ສະຖາປັດຕະນີ້ແມ່ນຫຼາຍກ່ວາ FaaS.

ຫຼັກການພື້ນຖານທີ່ຢູ່ເບື້ອງຫລັງເຕັກໂນໂລຢີ serverless ແມ່ນວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງກັງວົນກ່ຽວກັບການຄຸ້ມຄອງແລະການຂະຫຍາຍໂຄງສ້າງພື້ນຖານຂອງທ່ານ, ທ່ານພຽງແຕ່ຈ່າຍຄ່າສິ່ງທີ່ທ່ານໃຊ້. ການບໍລິການຫຼາຍຢ່າງເຫມາະສົມກັບເງື່ອນໄຂເຫຼົ່ານີ້ - AWS DynamoDB, S3, SNS ຫຼື SQS, Graphcool, Auth0, Now, Netlify, Firebase ແລະອື່ນໆຈໍານວນຫຼາຍ. ໂດຍທົ່ວໄປແລ້ວ, serverless ຫມາຍເຖິງການໃຊ້ພະລັງງານຢ່າງເຕັມທີ່ຂອງຄອມພິວເຕີ້ຟັງໂດຍບໍ່ຈໍາເປັນຕ້ອງຈັດການໂຄງສ້າງພື້ນຖານແລະເພີ່ມປະສິດທິພາບສໍາລັບຂະຫນາດ. ມັນຍັງຫມາຍຄວາມວ່າຄວາມປອດໄພໃນລະດັບພື້ນຖານໂຄງລ່າງບໍ່ແມ່ນຄວາມກັງວົນຂອງທ່ານອີກຕໍ່ໄປ, ເຊິ່ງເປັນຜົນປະໂຫຍດອັນໃຫຍ່ຫຼວງຍ້ອນຄວາມຫຍຸ້ງຍາກແລະຄວາມສັບສົນຂອງການຕອບສະຫນອງມາດຕະຖານຄວາມປອດໄພ. ສຸດທ້າຍ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງຊື້ໂຄງສ້າງພື້ນຖານທີ່ສະຫນອງໃຫ້ທ່ານ.

Serverless ສາມາດຖືວ່າເປັນ "ສະຖານະຂອງຈິດໃຈ": ຈິດໃຈທີ່ແນ່ນອນໃນເວລາທີ່ການອອກແບບການແກ້ໄຂ. ຫຼີກເວັ້ນການວິທີການທີ່ຕ້ອງການການບໍາລຸງຮັກສາພື້ນຖານໂຄງລ່າງ. ດ້ວຍວິທີການ serverless, ພວກເຮົາໃຊ້ເວລາແກ້ໄຂວຽກງານທີ່ມີຜົນກະທົບໂດຍກົງກັບໂຄງການແລະນໍາເອົາຜົນປະໂຫຍດມາໃຫ້ຜູ້ໃຊ້ຂອງພວກເຮົາ: ພວກເຮົາສ້າງເຫດຜົນທາງທຸລະກິດທີ່ຍືນຍົງ, ພັດທະນາການໂຕ້ຕອບຜູ້ໃຊ້ແລະພັດທະນາ APIs ທີ່ສາມາດປັບຕົວໄດ້ແລະເຊື່ອຖືໄດ້.

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

ບາງຄົນສັບສົນໂດຍການເພິ່ງພາອາໄສຜູ້ຂາຍໃນເວລາທີ່ພັດທະນາຄໍາຮ້ອງສະຫມັກຟັງ. ດຽວກັນນີ້ແມ່ນຄວາມຈິງກັບເຕັກໂນໂລຢີທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ, ແລະນີ້ບໍ່ຄ່ອຍເປັນຄວາມເຂົ້າໃຈຜິດ. ໃນປະສົບການຂອງພວກເຮົາ, ການສ້າງແອັບພລິເຄຊັນເຊີບເວີໃນ AWS, ບວກກັບຄວາມສາມາດຂອງ AWS Lambda ໃນການມັດບໍລິການ AWS ອື່ນໆຮ່ວມກັນ, ແມ່ນສ່ວນໜຶ່ງຂອງຄວາມເຂັ້ມແຂງຂອງສະຖາປັດຕະຍະກຳເຊີບເວີ. ນີ້ແມ່ນຕົວຢ່າງທີ່ດີຂອງ synergy, ໃນເວລາທີ່ຜົນໄດ້ຮັບຂອງການປະສົມປະສານແມ່ນຫຼາຍກ່ວາພຽງແຕ່ຜົນລວມຂອງຂໍ້ກໍານົດ. ການພະຍາຍາມຫຼີກລ່ຽງການຂຶ້ນກັບຜູ້ຂາຍສາມາດເຮັດໃຫ້ເກີດບັນຫາຫຼາຍຂຶ້ນ. ເມື່ອເຮັດວຽກກັບບັນຈຸ, ມັນງ່າຍກວ່າທີ່ຈະຈັດການຊັ້ນ abstraction ຂອງທ່ານເອງລະຫວ່າງຜູ້ໃຫ້ບໍລິການຟັງ. ແຕ່ໃນເວລາທີ່ມັນມາກັບການແກ້ໄຂ serverless, ຄວາມພະຍາຍາມຈະບໍ່ຈ່າຍອອກ, ໂດຍສະເພາະຖ້າຫາກວ່າຄ່າໃຊ້ຈ່າຍປະສິດທິພາບໄດ້ຖືກພິຈາລະນາໃນຕອນເລີ່ມຕົ້ນ. ໃຫ້ແນ່ໃຈວ່າຊອກຫາວິທີທີ່ຜູ້ຂາຍໃຫ້ບໍລິການ. ບາງການບໍລິການສະເພາະແມ່ນອີງໃສ່ຈຸດປະສົມປະສານກັບຜູ້ຂາຍອື່ນ ແລະອາດຈະໃຫ້ການເຊື່ອມຕໍ່ plug-and-play ອອກຈາກກ່ອງ. ມັນງ່າຍກວ່າທີ່ຈະສະຫນອງການໂທ Lambda ຈາກຈຸດສິ້ນສຸດ API gateway ກ່ວາການສົ່ງຄໍາຮ້ອງຂໍໃຫ້ກັບບາງ container ຫຼື EC2 instance. Graphcool ສະຫນອງການຕັ້ງຄ່າທີ່ງ່າຍດ້ວຍ Auth0, ເຊິ່ງງ່າຍກວ່າການໃຊ້ເຄື່ອງມືການກວດສອບພາກສ່ວນທີສາມ.

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

ພິ​ຈາ​ລະ​ນາ:

• ທ່ານຕ້ອງການບໍລິການອັນໃດ ແລະເປັນຫຍັງ.
• ບໍລິການໃດທີ່ຜູ້ໃຫ້ບໍລິການຄລາວສະໜອງໃຫ້ ແລະວິທີທີ່ເຈົ້າສາມາດລວມພວກມັນເຂົ້າກັບການແກ້ໄຂ FaaS ທີ່ທ່ານເລືອກ.
• ພາສາການຂຽນໂປລແກລມໃດທີ່ສະຫນັບສະຫນູນ (ດ້ວຍການພິມແບບເຄື່ອນໄຫວຫຼືແບບຄົງທີ່, ລວບລວມຫຼືຕີຄວາມ, ມາດຕະຖານແມ່ນຫຍັງ, ການປະຕິບັດການເລີ່ມຕົ້ນເຢັນແມ່ນຫຍັງ, ລະບົບນິເວດແຫຼ່ງເປີດແມ່ນຫຍັງ, ແລະອື່ນໆ).
• ຄວາມຕ້ອງການຄວາມປອດໄພຂອງເຈົ້າແມ່ນຫຍັງ (SLA, 2FA, OAuth, HTTPS, SSL, ແລະອື່ນໆ).
• ວິທີການຈັດການ CI/CD ແລະຮອບການພັດທະນາຊອບແວຂອງທ່ານ.
• ວິທີແກ້ໄຂໂຄງສ້າງພື້ນຖານທີ່ເປັນລະຫັດທີ່ເຈົ້າສາມາດໃຊ້ປະໂຫຍດຈາກ.

ຖ້າທ່ານຂະຫຍາຍແອັບພລິເຄຊັນທີ່ມີຢູ່ແລ້ວແລະເພີ່ມການເຮັດວຽກທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ, ນີ້ອາດຈະຈໍາກັດຄວາມສາມາດທີ່ມີຢູ່ບາງຢ່າງ. ຢ່າງໃດກໍຕາມ, ເກືອບທຸກເຕັກໂນໂລຊີ serverless ສະຫນອງບາງປະເພດຂອງ API (ຜ່ານ REST ຫຼືແຖວຂໍ້ຄວາມ) ທີ່ອະນຸຍາດໃຫ້ທ່ານເພື່ອສ້າງສ່ວນຂະຫຍາຍເປັນເອກະລາດຂອງຄໍາຮ້ອງສະຫມັກຫຼັກແລະປະສົມປະສານໄດ້ງ່າຍ. ຊອກຫາບໍລິການທີ່ມີ APIs ທີ່ຊັດເຈນ, ເອກະສານທີ່ດີ, ແລະຊຸມຊົນທີ່ເຂັ້ມແຂງ, ແລະທ່ານບໍ່ສາມາດຜິດພາດ. ຄວາມງ່າຍຂອງການເຊື່ອມໂຍງມັກຈະເປັນຕົວຊີ້ບອກທີ່ສໍາຄັນ, ແລະອາດຈະເປັນເຫດຜົນຕົ້ນຕໍທີ່ AWS ປະສົບຜົນສໍາເລັດຫຼາຍນັບຕັ້ງແຕ່ Lambda ຖືກປ່ອຍອອກມາໃນປີ 2015.

ເມື່ອ Serverless ດີ

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

ເນື່ອງຈາກການປະຫຍັດຄ່າໃຊ້ຈ່າຍແລະຄວາມງ່າຍຂອງການປັບຂະຫນາດ, ການແກ້ໄຂ serverless ແມ່ນໃຊ້ໄດ້ເທົ່າທຽມກັນສໍາລັບທັງລະບົບພາຍໃນແລະພາຍນອກ, ເຖິງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ມີຜູ້ຊົມຫຼາຍລ້ານຄົນ. ບັນຊີແມ່ນວັດແທກຫຼາຍກ່ວາໃນເອີໂຣ, ແຕ່ເປັນເຊັນ. ການເຊົ່າຕົວຢ່າງທີ່ງ່າຍດາຍທີ່ສຸດຂອງ AWS EC2 (t1.micro) ເປັນເວລາຫນຶ່ງເດືອນຈະມີລາຄາ 15 €, ເຖິງແມ່ນວ່າທ່ານຈະບໍ່ເຮັດຫຍັງກັບມັນ (ໃຜບໍ່ເຄີຍລືມປິດມັນ?!). ໃນການປຽບທຽບ, ເພື່ອບັນລຸລະດັບການໃຊ້ຈ່າຍນີ້ໃນໄລຍະເວລາດຽວກັນ, ທ່ານຈະຕ້ອງແລ່ນ Lambda 512 MB ສໍາລັບ 1 ວິນາທີປະມານ 3 ລ້ານເທື່ອ. ແລະຖ້າທ່ານບໍ່ໃຊ້ຄຸນສົມບັດນີ້, ທ່ານຈະບໍ່ຈ່າຍຄ່າຫຍັງ.

ເນື່ອງຈາກວ່າເຊີບເວີບໍ່ມີແມ່ນຂັບເຄື່ອນເຫດການຕົ້ນຕໍ, ມັນງ່າຍພໍສົມຄວນທີ່ຈະເພີ່ມໂຄງສ້າງພື້ນຖານເຊີບເວີໃຫ້ກັບລະບົບເກົ່າ. ຕົວຢ່າງ, ການນໍາໃຊ້ AWS S3, Lambda, ແລະ Kinesis, ທ່ານສາມາດສ້າງການບໍລິການການວິເຄາະສໍາລັບລະບົບການຂາຍຍ່ອຍເກົ່າທີ່ສາມາດຮັບຂໍ້ມູນຜ່ານ API.

ແພລະຕະຟອມທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍສ່ວນໃຫຍ່ສະຫນັບສະຫນູນຫຼາຍພາສາ. ສ່ວນຫຼາຍມັກມັນແມ່ນ Python, JavaScript, C#, Java ແລະ Go. ປົກກະຕິແລ້ວບໍ່ມີຂໍ້ຈໍາກັດໃນການນໍາໃຊ້ຫ້ອງສະຫມຸດໃນທຸກພາສາ, ດັ່ງນັ້ນທ່ານສາມາດນໍາໃຊ້ຫ້ອງສະຫມຸດ open source ທີ່ທ່ານມັກ. ຢ່າງໃດກໍ່ຕາມ, ມັນແນະນໍາໃຫ້ບໍ່ລ່ວງລະເມີດການເພິ່ງພາອາໄສເພື່ອໃຫ້ຫນ້າທີ່ຂອງທ່ານປະຕິບັດໄດ້ດີທີ່ສຸດແລະບໍ່ປະຕິເສດຜົນປະໂຫຍດຂອງການຂະຫຍາຍຂະຫນາດໃຫຍ່ຂອງແອັບພລິເຄຊັນທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍຂອງທ່ານ. ການຫຸ້ມຫໍ່ຫຼາຍທີ່ຕ້ອງໄດ້ຮັບການບັນຈຸເຂົ້າໄປໃນຖັງ, ການເລີ່ມຕົ້ນເຢັນຈະໃຊ້ເວລາດົນ.

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

ເຖິງແມ່ນວ່າ AWS ປ່ອຍອອກມາ ຖານຂໍ້ມູນ SQL serverless Serverless Auroraຢ່າງໃດກໍຕາມ, ຖານຂໍ້ມູນ SQL ບໍ່ເຫມາະສົມສໍາລັບຄໍາຮ້ອງສະຫມັກນີ້, ຍ້ອນວ່າພວກເຂົາຂຶ້ນກັບການເຊື່ອມຕໍ່ເພື່ອເຮັດທຸລະກໍາ, ເຊິ່ງສາມາດກາຍເປັນກະຕຸກຢ່າງໄວວາທີ່ມີການຈະລາຈອນຢ່າງຮຸນແຮງໃນ AWS Lambda. ແມ່ນແລ້ວ, ນັກພັດທະນາກໍາລັງປັບປຸງ Serverless Aurora ຢ່າງຕໍ່ເນື່ອງ, ແລະທ່ານຄວນທົດລອງກັບມັນ, ແຕ່ມື້ນີ້ NoSQL ແກ້ໄຂບັນຫາເຊັ່ນ: dynamodb. ຢ່າງໃດກໍ່ຕາມ, ບໍ່ມີຄວາມສົງໃສວ່າສະຖານະການນີ້ຈະມີການປ່ຽນແປງໃນໄວໆນີ້.

ຊຸດເຄື່ອງມືຍັງວາງຂໍ້ຈໍາກັດຫຼາຍຢ່າງ, ໂດຍສະເພາະໃນດ້ານການທົດສອບທ້ອງຖິ່ນ. ເຖິງແມ່ນວ່າມີການແກ້ໄຂເຊັ່ນ Docker-Lambda, DynamoDB Local ແລະ LocalStack, ພວກເຂົາຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກຫນັກແລະຈໍານວນການຕັ້ງຄ່າຢ່າງຫຼວງຫຼາຍ. ຢ່າງໃດກໍ່ຕາມ, ໂຄງການທັງຫມົດເຫຼົ່ານີ້ແມ່ນໄດ້ພັດທະນາຢ່າງຫ້າວຫັນ, ດັ່ງນັ້ນມັນພຽງແຕ່ເປັນເລື່ອງທີ່ໃຊ້ເວລາກ່ອນທີ່ຊຸດເຄື່ອງມືໄປຮອດລະດັບທີ່ພວກເຮົາຕ້ອງການ.

ຜົນກະທົບຂອງເຕັກໂນໂລຊີ serverless ໃນວົງຈອນການພັດທະນາ

ເນື່ອງຈາກວ່າໂຄງສ້າງພື້ນຖານຂອງທ່ານແມ່ນພຽງແຕ່ການຕັ້ງຄ່າ, ທ່ານສາມາດກໍານົດແລະນໍາໃຊ້ລະຫັດໂດຍໃຊ້ສະຄິບ, ເຊັ່ນ: shell scripts. ຫຼືທ່ານສາມາດ resort ກັບ configuration-as-code class solutions ເຊັ່ນ: ການສ້າງຄລາວຂອງ AWS. ເຖິງແມ່ນວ່າການບໍລິການນີ້ບໍ່ໄດ້ສະຫນອງການຕັ້ງຄ່າສໍາລັບທຸກພື້ນທີ່, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດຊັບພະຍາກອນສະເພາະເພື່ອໃຊ້ເປັນຫນ້າທີ່ Lambda. ນັ້ນແມ່ນ, ບ່ອນທີ່ CloudFormation ລົ້ມເຫລວ, ທ່ານສາມາດຂຽນຊັບພະຍາກອນຂອງທ່ານເອງ (ຟັງຊັນ Lambda) ທີ່ຈະປິດຊ່ອງຫວ່າງນີ້. ວິທີນີ້ເຈົ້າສາມາດເຮັດຫຍັງໄດ້, ເຖິງແມ່ນວ່າຈະຕັ້ງຄ່າການເພິ່ງພາອາໄສພາຍນອກສະພາບແວດລ້ອມ AWS ຂອງທ່ານ.

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

DevOps ມີຄວາມກັງວົນຫນ້ອຍລົງຍ້ອນວ່າພວກເຂົາພຽງແຕ່ຕ້ອງການໃຫ້ແນ່ໃຈວ່ານັກພັດທະນາມີການຕັ້ງຄ່າທີ່ຖືກຕ້ອງ. ທ່ານບໍ່ຈໍາເປັນຕ້ອງຈັດການ instances, balancers, ຫຼືກຸ່ມຄວາມປອດໄພອີກຕໍ່ໄປ. ດັ່ງນັ້ນ, ຄໍາສັບ NoOps ຖືກນໍາໃຊ້ເພີ່ມຂຶ້ນ, ເຖິງແມ່ນວ່າມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະສາມາດກໍານົດໂຄງສ້າງພື້ນຖານ, ໂດຍສະເພາະໃນເວລາທີ່ມັນມາກັບການຕັ້ງຄ່າ IAM ແລະການເພີ່ມປະສິດທິພາບຂອງຊັບພະຍາກອນຟັງ.

ມີເຄື່ອງມືຕິດຕາມ ແລະເບິ່ງພາບທີ່ມີປະສິດທິພາບຫຼາຍເຊັ່ນ Epsagon, Thundra, Dashbird ແລະ IOPipe. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານສາມາດຕິດຕາມກວດກາສະຖານະການໃນປະຈຸບັນຂອງຄໍາຮ້ອງສະຫມັກເຊີຟເວີຂອງທ່ານ, ສະຫນອງການບັນທຶກແລະການຕິດຕາມ, ຈັບຕົວວັດແທກການປະຕິບັດແລະຂໍ້ບົກພ່ອງຂອງສະຖາປັດຕະ, ປະຕິບັດການວິເຄາະຄ່າໃຊ້ຈ່າຍແລະການຄາດຄະເນ, ແລະອື່ນໆ. ພວກເຂົາບໍ່ພຽງແຕ່ໃຫ້ວິສະວະກອນ, ນັກພັດທະນາ, ແລະສະຖາປະນິກ DevOps ມີທັດສະນະທີ່ສົມບູນແບບຂອງການປະຕິບັດຂອງແອັບພລິເຄຊັນ, ແຕ່ຍັງໃຫ້ຜູ້ຈັດການຕິດຕາມສະຖານະການໃນເວລາທີ່ແທ້ຈິງ, ດ້ວຍຄ່າໃຊ້ຈ່າຍຕໍ່ຊັບພະຍາກອນແລະການຄາດຄະເນຄ່າໃຊ້ຈ່າຍຕໍ່ວິນາທີ. ມັນເປັນການຍາກຫຼາຍທີ່ຈະຈັດລະບຽບນີ້ດ້ວຍໂຄງສ້າງພື້ນຖານທີ່ມີການຄຸ້ມຄອງ.

ການອອກແບບແອັບພລິເຄຊັນທີ່ບໍ່ມີເຊີບເວີແມ່ນງ່າຍຂຶ້ນຫຼາຍເພາະວ່າທ່ານບໍ່ຈຳເປັນຕ້ອງນຳໃຊ້ເຊີບເວີເວັບ, ຈັດການເຄື່ອງ virtual ຫຼື containers, patch server, ລະບົບປະຕິບັດການ, internet gateways, ແລະອື່ນໆ. ໂດຍການຍົກເລີກຄວາມຮັບຜິດຊອບທັງໝົດເຫຼົ່ານີ້, ສະຖາປັດຕະຍະກຳ serverless ສາມາດເນັ້ນໃສ່ຫຼັກ - ການແກ້ໄຂ.ທຸລະກິດ ແລະຄວາມຕ້ອງການຂອງລູກຄ້າ.

ໃນຂະນະທີ່ຊຸດເຄື່ອງມືອາດຈະດີກວ່າ (ມັນດີຂຶ້ນທຸກໆມື້), ນັກພັດທະນາສາມາດສຸມໃສ່ການປະຕິບັດເຫດຜົນທາງທຸລະກິດແລະການແຈກຢາຍທີ່ດີທີ່ສຸດຂອງຄວາມສັບສົນຂອງຄໍາຮ້ອງສະຫມັກໃນທົ່ວການບໍລິການທີ່ແຕກຕ່າງກັນພາຍໃນສະຖາປັດຕະຍະກໍາ. ການຈັດການແອັບພລິເຄຊັນທີ່ບໍ່ມີເຊີບເວີແມ່ນອີງໃສ່ເຫດການ ແລະບໍ່ມີຕົວຕົນໂດຍຜູ້ໃຫ້ບໍລິການຄລາວ (ເຊັ່ນ: ເຫດການ SQS, S3 ຫຼືສະຕຣີມ DynamoDB). ດັ່ງນັ້ນ, ນັກພັດທະນາພຽງແຕ່ຕ້ອງການຂຽນເຫດຜົນທາງທຸລະກິດເພື່ອຕອບສະຫນອງຕໍ່ເຫດການບາງຢ່າງ, ແລະບໍ່ຈໍາເປັນຕ້ອງກັງວົນກ່ຽວກັບວິທີທີ່ດີທີ່ສຸດໃນການປະຕິບັດຖານຂໍ້ມູນແລະແຖວຂໍ້ຄວາມ, ຫຼືວິທີການຈັດລໍາດັບການເຮັດວຽກທີ່ດີທີ່ສຸດກັບຂໍ້ມູນໃນບ່ອນເກັບຮາດແວສະເພາະ.

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

ເຄື່ອງມືແລະເຕັກນິກການສ້າງຄໍາຮ້ອງສະຫມັກ serverless

ບໍ່ມີວິທີສະເພາະທີ່ຈະສ້າງແອັບພລິເຄຊັນທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ. ເຊັ່ນດຽວກັນກັບຊຸດການບໍລິການສໍາລັບວຽກງານນີ້. AWS ເປັນຜູ້ນໍາໃນບັນດາວິທີແກ້ໄຂ serverless ທີ່ມີປະສິດທິພາບໃນມື້ນີ້, ແຕ່ຍັງເບິ່ງ Google Cloud, ທີ່ໃຊ້ເວລາ и Firebase. ຖ້າທ່ານກໍາລັງໃຊ້ AWS, ຫຼັງຈາກນັ້ນວິທີການທີ່ແນະນໍາສໍາລັບການລວບລວມຄໍາຮ້ອງສະຫມັກແມ່ນ ຮູບແບບແອັບພລິເຄຊັນທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ (SAM), ໂດຍສະເພາະໃນເວລາທີ່ໃຊ້ C#, ເພາະວ່າ Visual Studio ມີເຄື່ອງມືທີ່ດີ. SAM CLI ສາມາດເຮັດທຸກຢ່າງທີ່ Visual Studio ສາມາດເຮັດໄດ້, ດັ່ງນັ້ນທ່ານຈະບໍ່ເສຍຫຍັງຖ້າທ່ານປ່ຽນໄປໃຊ້ IDE ຫຼືຕົວແກ້ໄຂຂໍ້ຄວາມອື່ນ. ແນ່ນອນ, SAM ເຮັດວຽກກັບພາສາອື່ນໆເຊັ່ນດຽວກັນ.

ຖ້າທ່ານກໍາລັງຂຽນໃນພາສາອື່ນ, Serverless Framework ເປັນເຄື່ອງມືແຫຼ່ງເປີດທີ່ດີເລີດທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດກໍາຫນົດຄ່າຫຍັງກັບໄຟລ໌ການຕັ້ງຄ່າ YAML ທີ່ມີປະສິດທິພາບຫຼາຍ. Serverless Framework ຍັງສະຫນັບສະຫນູນການບໍລິການຟັງຕ່າງໆ, ດັ່ງນັ້ນພວກເຮົາແນະນໍາໃຫ້ຜູ້ທີ່ກໍາລັງຊອກຫາການແກ້ໄຂຫຼາຍຄລາວ. ມັນ​ມີ​ຊຸມ​ຊົນ​ຂະ​ຫນາດ​ໃຫຍ່​ທີ່​ໄດ້​ສ້າງ​ຊໍ່​ຂອງ plugins ສໍາ​ລັບ​ຄວາມ​ຕ້ອງ​ການ​ໃດ​ຫນຶ່ງ.

ສໍາລັບການທົດສອບໃນທ້ອງຖິ່ນ, ເຄື່ອງມືເປີດ Docker-Lambda, Serverless Local, DynamoDB Local, ແລະ LocalStack ແມ່ນເຫມາະສົມດີ. ເຕັກໂນໂລຢີທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍແມ່ນຍັງຢູ່ໃນຂັ້ນຕອນຕົ້ນຂອງການພັດທະນາ, ເຊັ່ນດຽວກັນກັບເຄື່ອງມືສໍາລັບພວກເຂົາ, ດັ່ງນັ້ນເມື່ອຕັ້ງຄ່າສະຖານະການທົດສອບທີ່ສັບສົນ, ທ່ານຈະຕ້ອງເຮັດວຽກຫນັກ. ຢ່າງໃດກໍຕາມ, ພຽງແຕ່ນໍາໃຊ້ stack ໃນສະພາບແວດລ້ອມແລະການທົດສອບມີລາຄາຖືກ incredibly. ແລະທ່ານບໍ່ຈໍາເປັນຕ້ອງເຮັດສໍາເນົາທ້ອງຖິ່ນທີ່ແນ່ນອນຂອງສະພາບແວດລ້ອມຟັງ.

ໃຊ້ AWS Lambda Layers ເພື່ອຫຼຸດຂະໜາດຂອງແພັກເກັດທີ່ນຳໃຊ້ ແລະເລັ່ງການດາວໂຫຼດ.

ໃຊ້ພາສາການຂຽນໂປຼແກຼມທີ່ເຫມາະສົມກັບວຽກງານສະເພາະ. ພາສາທີ່ແຕກຕ່າງກັນມີຂໍ້ດີແລະຂໍ້ເສຍຂອງຕົນເອງ. ມີຫຼາຍ benchmarks, ແຕ່ JavaScript, Python, ແລະ C# (.NET Core 2.1+) ແມ່ນຜູ້ນໍາທາງດ້ານການປະຕິບັດຂອງ AWS Lambda. ບໍ່ດົນມານີ້ AWS Lambda ໄດ້ນໍາສະເຫນີ Runtime API, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານລະບຸພາສາ runtime ທີ່ຕ້ອງການຂອງທ່ານແລະສະພາບແວດລ້ອມ, ດັ່ງນັ້ນການທົດລອງ.

ຮັກສາຂະໜາດແພັກເກັດນ້ອຍໆໄວ້ເພື່ອນຳໃຊ້. ເຂົາເຈົ້າມີຂະຫນາດນ້ອຍກວ່າ, ເຂົາເຈົ້າໂຫຼດໄວຂຶ້ນ. ຫຼີກເວັ້ນການນໍາໃຊ້ຫ້ອງສະຫມຸດຂະຫນາດໃຫຍ່, ໂດຍສະເພາະຖ້າທ່ານໃຊ້ສອງສາມລັກສະນະຈາກພວກມັນ. ຖ້າທ່ານກໍາລັງຂຽນໂປລແກລມໃນ JavaScript, ໃຊ້ເຄື່ອງມືສ້າງເຊັ່ນ Webpack ເພື່ອເພີ່ມປະສິດທິພາບການສ້າງຂອງທ່ານແລະພຽງແຕ່ລວມເອົາສິ່ງທີ່ທ່ານຕ້ອງການແທ້ໆ. .NET Core 3.0 ມີ QuickJit ແລະ Tiered Compilation ທີ່ປັບປຸງປະສິດທິພາບ ແລະຊ່ວຍໄດ້ຫຼາຍໃນການເລີ່ມຕົ້ນເຢັນ.

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

ສະຫລຸບ

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com