Serverless ໃນ racks

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

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

ຈະເປັນແນວໃດຖ້າພວກເຮົາເອົາຕູ້ຄອນເທນເນີ ephemeral, ໃນທີ່ dependencies ທີ່ຈໍາເປັນໄດ້ຖືກຕິດຕັ້ງໄວ້ກ່ອນແລ້ວ, ແລະ containers ຕົວຂອງມັນເອງຖືກແຍກອອກຈາກກັນແລະຈາກ host OS? ພວກເຮົາຈະແບ່ງ monolith ເຂົ້າໄປໃນ microservices, ແຕ່ລະອັນສາມາດປັບປຸງແລະຂະຫນາດເປັນເອກະລາດຂອງຄົນອື່ນ. ໂດຍການວາງລະຫັດໄວ້ໃນຖັງດັ່ງກ່າວ, ຂ້ອຍສາມາດດໍາເນີນການໄດ້ໃນໂຄງສ້າງໃດກໍ່ຕາມ. ດີຂຶ້ນແລ້ວ.

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

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

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

ໃຫ້ເຮົາເບິ່ງວ່າຂະບວນການພັດທະນາແອັບພລິເຄຊັນຈະມີລັກສະນະແນວໃດໃນປັດຈຸບັນ.

ຈາກຝ່າຍພັດທະນາ

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

ເພື່ອຍ້າຍໄປ serverless, ພວກເຮົາແຍກແອັບພລິເຄຊັນອອກເປັນ microtasks. ພວກເຮົາຂຽນຫນ້າທີ່ຂອງພວກເຮົາສໍາລັບແຕ່ລະຄົນ. ຫນ້າທີ່ເປັນເອກະລາດຂອງກັນແລະກັນແລະບໍ່ເກັບຮັກສາຂໍ້ມູນຂອງລັດ (ບໍ່ມີລັດ). ເຂົາເຈົ້າອາດຈະຂຽນເປັນພາສາຕ່າງໆ. ຖ້າຫນຶ່ງຂອງພວກເຂົາ "ຕົກ", ຄໍາຮ້ອງສະຫມັກທັງຫມົດຈະບໍ່ຢຸດ. ສະຖາປັດຕະຍະກໍາຂອງຄໍາຮ້ອງສະຫມັກຈະມີລັກສະນະນີ້:

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

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

ພວກເຮົາກໍານົດເຫດການໃຫ້ແຕ່ລະຫນ້າທີ່. ເຫດການເປັນຕົວກະຕຸ້ນໃຫ້ເກີດການກະທຳ:

ເຫດການ
ການປະຕິບັດຫນ້າທີ່ປະຕິບັດ

ຮູບພາບຜະລິດຕະພັນໄດ້ຖືກອັບໂຫລດໃສ່ບ່ອນເກັບມ້ຽນ.
ບີບອັດຮູບພາບແລະອັບໂຫລດໄປຍັງໄດເລກະທໍລີ

ທີ່ຢູ່ຮ້ານຄ້າທາງດ້ານຮ່າງກາຍໄດ້ຖືກປັບປຸງຢູ່ໃນຖານຂໍ້ມູນ
ໂຫຼດສະຖານທີ່ໃໝ່ໃສ່ແຜນທີ່

ລູກຄ້າຈ່າຍຄ່າສິນຄ້າ
ເລີ່ມການປະມວນຜົນການຈ່າຍເງິນ

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

ສະຖາປັດຕະຍະກໍາໄດ້ຖືກເຮັດວຽກອອກ, ແລະຄໍາຮ້ອງສະຫມັກເກືອບກາຍເປັນ serverless. ຕໍ່ໄປພວກເຮົາໄປຫາຜູ້ໃຫ້ບໍລິການ.

ຈາກຝ່າຍຜູ້ໃຫ້ບໍລິການ

ໂດຍປົກກະຕິ, ຄອມພິວເຕີ້ທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍແມ່ນສະຫນອງໃຫ້ໂດຍຜູ້ໃຫ້ບໍລິການຄລາວ. ພວກເຂົາຖືກເອີ້ນແຕກຕ່າງກັນ: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

ພວກເຮົາຈະໃຊ້ບໍລິການຜ່ານ console ຂອງຜູ້ໃຫ້ບໍລິການ ຫຼືບັນຊີສ່ວນຕົວ. ລະຫັດຟັງຊັນສາມາດດາວໂຫຼດໄດ້ດ້ວຍວິທີໜຶ່ງຕໍ່ໄປນີ້:

• ຂຽນລະຫັດໃນຕົວແກ້ໄຂຜ່ານ web console,
• ດາວ​ນ​໌​ໂຫລດ​ແຟ້ມ​ຈັດ​ເກັບ​ທີ່​ມີ​ລະ​ຫັດ​,
• ເຮັດວຽກກັບ git repositories ສາທາລະນະຫຼືເອກະຊົນ.

ໃນທີ່ນີ້ພວກເຮົາຕັ້ງຄ່າເຫດການທີ່ເອີ້ນຟັງຊັນ. ຊຸດຂອງເຫດການອາດຈະແຕກຕ່າງກັນສໍາລັບຜູ້ໃຫ້ບໍລິການທີ່ແຕກຕ່າງກັນ.

ຜູ້ໃຫ້ບໍລິການສ້າງແລະອັດຕະໂນມັດລະບົບ Function as a Service (FaaS) ໃນໂຄງສ້າງພື້ນຖານຂອງມັນ:

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

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

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

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

ຈາກດ້ານແຫຼ່ງເປີດ

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

• ກູໂກ ສະເໜີໃຫ້ຜູ້ພັດທະນາເຄື່ອງມືເປີດແຫຼ່ງຂອງຕົນ - ພື້ນເມືອງ. IBM, RedHat, Pivotal ແລະ SAP ໄດ້ເຂົ້າຮ່ວມໃນການພັດທະນາຂອງຕົນ;
• IBM ໄດ້ເຮັດວຽກຢູ່ໃນເວທີ Serverless OpenWhisk, ເຊິ່ງຫຼັງຈາກນັ້ນໄດ້ກາຍເປັນໂຄງການຂອງ Apache Foundation;
• Microsoft ເປີດບາງສ່ວນລະຫັດເວທີ ຟັງຊັນ Azure.

ການພັດທະນາຍັງດໍາເນີນຢູ່ໃນທິດທາງຂອງກອບ serverless. Kubeless и ຄວາມຜິດ ນຳໃຊ້ພາຍໃນກຸ່ມ Kubernetes ທີ່ກຽມໄວ້ລ່ວງໜ້າ, OpenFaaS ເຮັດວຽກກັບທັງ Kubernetes ແລະ Docker Swarm. ກອບເຮັດຫນ້າທີ່ເປັນຕົວຄວບຄຸມປະເພດຫນຶ່ງ - ຕາມການຮ້ອງຂໍ, ມັນກະກຽມສະພາບແວດລ້ອມ runtime ພາຍໃນ cluster, ຫຼັງຈາກນັ້ນເປີດຕົວຟັງຊັນຢູ່ທີ່ນັ້ນ.

Frameworks ອອກຈາກຫ້ອງສໍາລັບການຕັ້ງຄ່າເຄື່ອງມືໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງທ່ານ. ດັ່ງນັ້ນ, ໃນ Kubeless, ນັກພັດທະນາສາມາດຕັ້ງຄ່າການຫມົດເວລາການປະຕິບັດຫນ້າທີ່ (ຄ່າເລີ່ມຕົ້ນແມ່ນ 180 ວິນາທີ). Fission, ໃນຄວາມພະຍາຍາມທີ່ຈະແກ້ໄຂບັນຫາການເລີ່ມຕົ້ນຂອງຄວາມເຢັນ, ແນະນໍາການຮັກສາຕູ້ຄອນເທນເນີບາງອັນເຮັດວຽກຕະຫຼອດເວລາ (ເຖິງແມ່ນວ່ານີ້ປະກອບມີຄ່າໃຊ້ຈ່າຍໃນການຢຸດເວລາຂອງຊັບພະຍາກອນ). ແລະ OpenFaaS ສະຫນອງຊຸດຂອງ triggers ສໍາລັບທຸກໆລົດຊາດແລະສີ: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs ແລະອື່ນໆ.

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

ບໍ່ວ່າພວກເຮົາເຮັດວຽກກັບ Serverless ແນວໃດ - ຜ່ານຜູ້ໃຫ້ບໍລິການຫຼືໃຊ້ open-source, ພວກເຮົາຈະໄດ້ຮັບຂໍ້ດີແລະຂໍ້ເສຍຫຼາຍຢ່າງຂອງວິທີການ Serverless.

ຈາກທັດສະນະຂອງຂໍ້ດີແລະຂໍ້ເສຍ

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

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

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

ເຊັ່ນດຽວກັນກັບເຕັກໂນໂລຢີໃດກໍ່ຕາມ, Serverless ມີຂໍ້ເສຍປຽບ.

ຕົວຢ່າງ, ຂໍ້ເສຍດັ່ງກ່າວອາດຈະເປັນເວລາເລີ່ມຕົ້ນທີ່ເຢັນ (ໂດຍສະເລ່ຍເຖິງ 1 ວິນາທີສໍາລັບພາສາເຊັ່ນ JavaScript, Python, Go, Java, Ruby).

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

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

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

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

ຂໍ້ເສຍຕໍ່ໄປຂອງ Serverless ແມ່ນອາຍຸຂອງຟັງຊັນສັ້ນ (ໝົດເວລາທີ່ຟັງຊັນຕ້ອງຖືກປະຕິບັດ).

ແຕ່, ຖ້າທ່ານຕ້ອງເຮັດວຽກກັບວຽກງານທີ່ມີຊີວິດຊີວາ, ທ່ານສາມາດນໍາໃຊ້ສະຖາປັດຕະຍະກໍາປະສົມ - ປະສົມປະສານ Serverless ກັບເຕັກໂນໂລຢີອື່ນ.

ບໍ່ແມ່ນທຸກລະບົບຈະສາມາດເຮັດວຽກໄດ້ໂດຍໃຊ້ລະບົບ Serverless.

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

ໃນເສັ້ນກ່າງນີ້, ຂ້າພະເຈົ້າຢາກຈະກ້າວໄປສູ່ບັນຫາຂອງການນໍາໃຊ້ວິທີການ Serverless ຢ່າງລຽບງ່າຍ.

ຈາກດ້ານຄໍາຮ້ອງສະຫມັກ

ສໍາລັບ 2018, ອັດຕາສ່ວນຂອງການນໍາໃຊ້ Serverless ເພີ່ມຂຶ້ນຫນຶ່ງແລະເຄິ່ງຫນຶ່ງເທົ່າ. ໃນ​ບັນ​ດາ​ບໍ​ລິ​ສັດ​ທີ່​ໄດ້​ປະ​ຕິ​ບັດ​ເຕັກ​ໂນ​ໂລ​ຊີ​ໃນ​ການ​ບໍ​ລິ​ການ​ຂອງ​ເຂົາ​ເຈົ້າ​ແມ່ນ​ຍັກ​ໃຫຍ່​ຕະ​ຫຼາດ​ເຊັ່ນ Twitter​, PayPal​, Netflix​, T​-Mobile​, Coca​-Cola​. ໃນເວລາດຽວກັນ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າ Serverless ບໍ່ແມ່ນ panacea, ແຕ່ເປັນເຄື່ອງມືສໍາລັບການແກ້ໄຂບັນຫາສະເພາະໃດຫນຶ່ງ:

• ຫຼຸດ​ຜ່ອນ​ການ​ຢຸດ​ເຊົາ​ຊັບ​ພະ​ຍາ​ກອນ​. ບໍ່ຈໍາເປັນຕ້ອງຮັກສາເຄື່ອງ virtual ຢູ່ສະເຫມີສໍາລັບການບໍລິການທີ່ມີການໂທຈໍານວນຫນ້ອຍ.
• ຂະບວນການຂໍ້ມູນໃນການບິນ. ບີບອັດຮູບພາບ, ຕັດພື້ນຫລັງ, ປ່ຽນການເຂົ້າລະຫັດວິດີໂອ, ເຮັດວຽກກັບເຊັນເຊີ IoT, ປະຕິບັດການທາງຄະນິດສາດ.
• "ກາວ" ບໍລິການອື່ນໆຮ່ວມກັນ. Git repository ກັບໂຄງການພາຍໃນ, chat bot ໃນ Slack ກັບ Jira ແລະປະຕິທິນ.
• ດຸ່ນດ່ຽງການໂຫຼດ. ລອງເບິ່ງໃກ້ໆທີ່ນີ້.

ໃຫ້ເວົ້າວ່າມີບໍລິການທີ່ດຶງດູດ 50 ຄົນ. ພາຍໃຕ້ມັນມີເຄື່ອງ virtual ທີ່ມີຮາດແວທີ່ອ່ອນແອ. ຈາກທີ່ໃຊ້ເວລາ, ການໂຫຼດໃນການບໍລິການເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ຫຼັງຈາກນັ້ນ, ຮາດແວທີ່ອ່ອນແອບໍ່ສາມາດຮັບມືກັບ.

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

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

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

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

Serverless ແລະ Selectel

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

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

• ເປີເຊັນຂອງການນໍາໃຊ້ Serverless ໄດ້ເພີ່ມຂຶ້ນຫນຶ່ງເທື່ອເຄິ່ງ (ບົດລາຍງານ RightScale ເຕັມ)
• ເວລາເລີ່ມຕົ້ນເຢັນເທົ່າໃດແມ່ນຂຶ້ນກັບພາສາຂອງແອັບພລິເຄຊັນ

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