ชุมชนนักพัฒนาถกเถียงเครื่องมือพัฒนา AWS Lambda แบบโลคอล: เป็นระบบ Serverless จริงหรือแค่บริการโฮสติ้งในชื่อใหม่?

BigGo Editorial Team
ชุมชนนักพัฒนาถกเถียงเครื่องมือพัฒนา AWS Lambda แบบโลคอล: เป็นระบบ Serverless จริงหรือแค่บริการโฮสติ้งในชื่อใหม่?

การเปิดตัว 'fun' ซึ่งเป็นรันไทม์สำหรับพัฒนาฟังก์ชัน serverless แบบโลคอล ได้จุดประเด็นการถกเถียงที่น่าสนใจในชุมชนนักพัฒนาเกี่ยวกับธรรมชาติและประโยชน์ของการประมวลผลแบบ serverless โดยเฉพาะอย่างยิ่งในส่วนของ AWS Lambda functions แม้ว่าเครื่องมือนี้มีจุดมุ่งหมายเพื่อทำให้การพัฒนาแบบโลคอลง่ายขึ้นด้วยการจำลองสภาพแวดล้อมของ Lambda แต่ก็ได้จุดประเด็นการอภิปรายเกี่ยวกับแนวคิดพื้นฐานของสถาปัตยกรรมแบบ serverless ขึ้นมาอีกครั้ง

สภาพแวดล้อมการทำงานที่รองรับ:

  • Node.js: ระบบ node, เวอร์ชัน v6.10.0, v8.10.0, v10.15.3, v12.22.7, v14.18.1
  • Python: ระบบ python, เวอร์ชัน v2.7.12, ระบบ python3, v3.6.8, v3.7.2
  • Go: go1.x (ต้องการการคอมไพล์เฉพาะแพลตฟอร์ม)
  • แบบกำหนดเอง: มีการรองรับการทำงาน

วิกฤตอัตลักษณ์ของ Serverless

ชุมชนนักพัฒนาได้ตั้งคำถามที่น่าคิดเกี่ยวกับคำศัพท์และการตลาดของเทคโนโลยี serverless โดยมีการวิพากษ์วิจารณ์ที่น่าสนใจจากชุมชนว่า:

ผมไม่ชอบที่เรียกสิ่งเหล่านี้ว่า lambdas หรือแม้แต่คำว่า serverless โดยรวม มันไม่ได้บริสุทธิ์อย่างที่ว่าและมันทำงานบนเซิร์ฟเวอร์จริงๆ... มันก็คือระบบปฏิบัติการนั่นเอง

มุมมองนี้สะท้อนให้เห็นการถกเถียงที่ยังคงดำเนินอยู่ว่า serverless เป็นเพียงกลยุทธ์การตลาดที่ฉลาดสำหรับโฮสติ้งแบบดั้งเดิมในรูปแบบที่ทันสมัยขึ้นหรือไม่ โดยนักพัฒนาบางคนเปรียบเทียบกับรูปแบบการให้บริการโฮสติ้ง PHP แบบใช้ร่วมกัน

การประยุกต์ใช้งานจริงและความท้าทายในการพัฒนา

แม้จะมีการถกเถียงในเชิงปรัชญา การสนทนาในชุมชนแสดงให้เห็นถึงความสนใจจริงๆ ในการประยุกต์ใช้ Lambda นักพัฒนากำลังมองหากรณีการใช้งานและเปรียบเทียบวิธีการพัฒนาที่แตกต่างกัน รันไทม์ 'fun' พยายามตอบสนองความต้องการที่สำคัญด้วยการจัดเตรียมสภาพแวดล้อมการพัฒนาที่ใกล้เคียงกับสภาพแวดล้อมการผลิตจริงของ AWS Lambda แม้จะมีข้อจำกัดที่ทราบกันดี เช่น บริบทผู้ใช้ที่แตกต่างกันและกลไกการแซนด์บ็อกซ์

ข้อจำกัดที่สำคัญ:

  • ทำงานในฐานะผู้ใช้งานในเครื่องแทนที่จะเป็น sbx_user1051
  • ไม่มีการแซนด์บ็อกซ์กระบวนการหรือ chroot
  • ใช้ SIGSTOP/SIGCONT สำหรับการหยุดกระบวนการชั่วคราว
  • โปรแกรมที่ประมวลผลโดยตรงต้องถูกคอมไพล์สำหรับระบบปฏิบัติการในเครื่อง

ทางเลือกอื่นและความชอบของชุมชน

การอภิปรายได้เน้นให้เห็นถึงวิธีการทางเลือกหลายแบบสำหรับการพัฒนา Lambda แบบโลคอล รวมถึง SST (sst.dev) ซึ่งนำเสนอความสามารถในการพัฒนา Lambda แบบโลคอลโดยตรง นักพัฒนาบางคนที่มีประสบการณ์กับ Serverless Framework แสดงความสนใจใน 'fun' ว่าอาจเป็นทางเลือกที่ง่ายกว่า แม้ว่าบางคนจะระบุว่ามันมีจุดประสงค์ที่แตกต่างกัน โดยมุ่งเน้นไปที่การจำลองรันไทม์แบบโลคอลมากกว่าการจัดการการเผยแพร่แบบเต็มรูปแบบ

ข้อพิจารณาด้านเทคนิคในการนำไปใช้

การนำเครื่องมือไปใช้เผยให้เห็นข้อพิจารณาทางเทคนิคที่สำคัญสำหรับการพัฒนา Lambda โดยรองรับ Node.js หลายเวอร์ชัน (ตั้งแต่ 6.10 ถึง 14.x) และรันไทม์ Python แม้ว่าสมาชิกในชุมชนบางคนจะสังเกตเห็นว่าขาดการรองรับ Ruby ความแตกต่างของรันไทม์ระหว่างการพัฒนาแบบโลคอลและสภาพแวดล้อมการผลิต โดยเฉพาะในส่วนของการจัดการกระบวนการและบริบทด้านความปลอดภัย ยังคงเป็นข้อพิจารณาสำคัญสำหรับนักพัฒนา

สรุปได้ว่า ในขณะที่ 'fun' เป็นเครื่องมือที่มีประโยชน์สำหรับการพัฒนา Lambda แบบโลคอล การอภิปรายในชุมชนได้เผยให้เห็นคำถามที่กว้างขึ้นเกี่ยวกับกระบวนทัศน์ serverless และการนำไปใช้ การถกเถียงเหล่านี้ยังคงมีอิทธิพลต่อวิธีที่นักพัฒนาเข้าถึงกลยุทธ์การพัฒนาและการเผยแพร่ฟังก์ชันบนคลาวด์

อ้างอิง: fun - Local serverless function λ development runtime