โปรโฮสต์ > บล็อก > การบริหาร > ไร้เซิร์ฟเวอร์บนชั้นวาง

ไร้เซิร์ฟเวอร์บนชั้นวาง

ไร้เซิร์ฟเวอร์บนชั้นวาง
Serverless ไม่ได้เกี่ยวกับการไม่มีเซิร์ฟเวอร์ทางกายภาพ นี่ไม่ใช่การฆ่าคอนเทนเนอร์หรือกระแสที่ผ่านไป นี่เป็นแนวทางใหม่ในการสร้างระบบในระบบคลาวด์ ในบทความวันนี้ เราจะพูดถึงสถาปัตยกรรมของแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ มาดูกันว่าผู้ให้บริการแบบไร้เซิร์ฟเวอร์และโปรเจ็กต์โอเพ่นซอร์สมีบทบาทอย่างไร สุดท้ายนี้ เรามาพูดถึงปัญหาการใช้งาน Serverless กันดีกว่า

ฉันต้องการเขียนส่วนเซิร์ฟเวอร์ของแอปพลิเคชัน (หรือแม้แต่ร้านค้าออนไลน์) นี่อาจเป็นการแชท บริการเผยแพร่เนื้อหา หรือตัวจัดสรรภาระงาน ไม่ว่าในกรณีใด คุณจะต้องปวดหัวมาก: คุณจะต้องเตรียมโครงสร้างพื้นฐาน พิจารณาการขึ้นต่อกันของแอปพลิเคชัน และคิดถึงระบบปฏิบัติการของโฮสต์ จากนั้นคุณจะต้องอัปเดตส่วนประกอบขนาดเล็กที่ไม่ส่งผลต่อการทำงานของส่วนที่เหลือของหินใหญ่ก้อนเดียว อย่าลืมเกี่ยวกับการปรับขนาดภายใต้ภาระงาน

จะเกิดอะไรขึ้นถ้าเราใช้คอนเทนเนอร์ชั่วคราวซึ่งมีการติดตั้งการขึ้นต่อกันที่จำเป็นไว้ล่วงหน้าแล้ว และตัวคอนเทนเนอร์เองก็แยกออกจากกันและจากระบบปฏิบัติการโฮสต์ เราจะแบ่งโมโนลิธออกเป็นไมโครเซอร์วิส ซึ่งแต่ละไมโครเซอร์วิสสามารถอัปเดตและปรับขนาดได้โดยแยกจากไมโครเซอร์วิสอื่นๆ ด้วยการวางโค้ดลงในคอนเทนเนอร์ดังกล่าว ฉันสามารถรันโค้ดบนโครงสร้างพื้นฐานใดก็ได้ ดีขึ้นแล้ว.

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

ความคิดเช่นนั้นนำฉันไปสู่การประมวลผลแบบไร้เซิร์ฟเวอร์ Serverless ในกรณีนี้หมายถึง ไม่ใช่การไม่มีเซิร์ฟเวอร์ทางกายภาพ แต่ไม่มีการปวดหัวในการจัดการโครงสร้างพื้นฐาน

แนวคิดก็คือตรรกะของแอปพลิเคชันถูกแบ่งออกเป็นฟังก์ชันอิสระ พวกเขามีโครงสร้างเหตุการณ์ แต่ละฟังก์ชันทำหน้าที่ "ไมโครทาสก์" หนึ่งรายการ สิ่งที่นักพัฒนาต้องการคือโหลดฟังก์ชันต่างๆ ลงในคอนโซลที่ผู้ให้บริการระบบคลาวด์จัดเตรียมไว้ให้ และเชื่อมโยงกับแหล่งที่มาของเหตุการณ์ รหัสจะถูกดำเนินการตามความต้องการในคอนเทนเนอร์ที่จัดเตรียมโดยอัตโนมัติ และฉันจะจ่ายเฉพาะเวลาดำเนินการเท่านั้น

มาดูกันว่ากระบวนการพัฒนาแอพพลิเคชั่นจะเป็นอย่างไรในตอนนี้

จากฝั่งผู้พัฒนา

ก่อนหน้านี้เราเริ่มพูดถึงแอปพลิเคชันสำหรับร้านค้าออนไลน์ ในแนวทางดั้งเดิม ตรรกะหลักของระบบดำเนินการโดยแอปพลิเคชันเสาหิน และเซิร์ฟเวอร์ที่มีแอปพลิเคชันทำงานอย่างต่อเนื่องแม้ว่าจะไม่มีการโหลดก็ตาม

หากต้องการเปลี่ยนไปใช้แบบไร้เซิร์ฟเวอร์ เราจะแบ่งแอปพลิเคชันออกเป็นไมโครทาสก์ เราเขียนฟังก์ชันของเราเองสำหรับแต่ละรายการ ฟังก์ชันต่างๆ มีความเป็นอิสระจากกันและไม่ได้จัดเก็บข้อมูลสถานะ (ไร้สัญชาติ) อาจเขียนเป็นภาษาต่างๆ ก็ได้ หากหนึ่งในนั้น "ล้ม" แอปพลิเคชันทั้งหมดจะไม่หยุด สถาปัตยกรรมแอปพลิเคชันจะมีลักษณะดังนี้:

ไร้เซิร์ฟเวอร์บนชั้นวาง
การแบ่งออกเป็นฟังก์ชันใน Serverless นั้นคล้ายคลึงกับการทำงานกับไมโครเซอร์วิส แต่ไมโครเซอร์วิสสามารถทำงานได้หลายอย่าง และฟังก์ชันหนึ่งๆ ก็ควรจะทำงานอย่างใดอย่างหนึ่งได้ดี ลองจินตนาการว่างานคือการรวบรวมสถิติและแสดงตามคำขอของผู้ใช้ ในแนวทางไมโครเซอร์วิส งานจะดำเนินการโดยบริการเดียวที่มีจุดเข้าใช้งานสองจุด: การเขียนและการอ่าน ในการประมวลผลแบบไร้เซิร์ฟเวอร์ ฟังก์ชันเหล่านี้จะเป็นสองฟังก์ชันที่แตกต่างกันซึ่งไม่เกี่ยวข้องกัน นักพัฒนาซอฟต์แวร์จะบันทึกทรัพยากรการประมวลผล เช่น หากมีการอัปเดตสถิติบ่อยกว่าที่ดาวน์โหลด

ฟังก์ชันไร้เซิร์ฟเวอร์จะต้องดำเนินการในช่วงเวลาอันสั้น (หมดเวลา) ซึ่งกำหนดโดยผู้ให้บริการ ตัวอย่างเช่น สำหรับ AWS การหมดเวลาคือ 15 นาที ซึ่งหมายความว่าจะต้องเปลี่ยนฟังก์ชันที่มีอายุการใช้งานยาวนานเพื่อให้เหมาะกับความต้องการ - นี่คือสิ่งที่ทำให้ Serverless แตกต่างจากเทคโนโลยียอดนิยมอื่นๆ ในปัจจุบัน (คอนเทนเนอร์และแพลตฟอร์มเป็นบริการ)

เรากำหนดเหตุการณ์ให้กับแต่ละฟังก์ชัน เหตุการณ์เป็นตัวกระตุ้นให้เกิดการกระทำ:

เหตุการณ์
การดำเนินการที่ฟังก์ชันดำเนินการ

อัปโหลดรูปภาพผลิตภัณฑ์ไปยังที่เก็บแล้ว
บีบอัดรูปภาพและอัปโหลดไปยังไดเร็กทอรี

ที่อยู่ร้านค้าทางกายภาพได้รับการอัปเดตในฐานข้อมูลแล้ว
โหลดตำแหน่งใหม่ลงในแผนที่

ลูกค้าชำระค่าสินค้า
เริ่มการประมวลผลการชำระเงิน

เหตุการณ์อาจเป็นคำขอ HTTP ข้อมูลการสตรีม คิวข้อความ และอื่นๆ แหล่งที่มาของเหตุการณ์คือการเปลี่ยนแปลงหรือการเกิดข้อมูล นอกจากนี้ ฟังก์ชันยังสามารถทริกเกอร์ได้ด้วยตัวจับเวลา

สถาปัตยกรรมได้รับการพัฒนา และแอปพลิเคชันเกือบจะกลายเป็นระบบไร้เซิร์ฟเวอร์ ต่อไปเราไปที่ผู้ให้บริการ

จากฝั่งผู้ให้บริการ

โดยทั่วไปแล้ว ผู้ให้บริการระบบคลาวด์จะนำเสนอการประมวลผลแบบไร้เซิร์ฟเวอร์ มีชื่อเรียกต่างกัน: ฟังก์ชัน Azure, AWS Lambda, ฟังก์ชัน Google Cloud, ฟังก์ชัน IBM Cloud

เราจะใช้บริการผ่านคอนโซลของผู้ให้บริการหรือบัญชีส่วนตัว สามารถดาวน์โหลดโค้ดฟังก์ชันได้ด้วยวิธีใดวิธีหนึ่งต่อไปนี้:

  • เขียนโค้ดในตัวแก้ไขในตัวผ่านเว็บคอนโซล
  • ดาวน์โหลดไฟล์เก็บถาวรพร้อมรหัส
  • ทำงานร่วมกับที่เก็บ Git สาธารณะหรือส่วนตัว

ที่นี่เราตั้งค่าเหตุการณ์ที่เรียกใช้ฟังก์ชัน ชุดกิจกรรมอาจแตกต่างกันไปตามผู้ให้บริการแต่ละราย

ไร้เซิร์ฟเวอร์บนชั้นวาง

ผู้ให้บริการสร้างและทำให้ระบบ Function as a Service (FaaS) เป็นแบบอัตโนมัติบนโครงสร้างพื้นฐาน:

  1. รหัสฟังก์ชันจะสิ้นสุดในที่เก็บข้อมูลฝั่งผู้ให้บริการ
  2. เมื่อมีเหตุการณ์เกิดขึ้น คอนเทนเนอร์ที่มีสภาพแวดล้อมที่เตรียมไว้จะถูกปรับใช้บนเซิร์ฟเวอร์โดยอัตโนมัติ แต่ละอินสแตนซ์ของฟังก์ชันมีคอนเทนเนอร์แยกของตัวเอง
  3. จากที่เก็บข้อมูล ฟังก์ชันจะถูกส่งไปยังคอนเทนเนอร์ คำนวณ และส่งกลับผลลัพธ์
  4. จำนวนเหตุการณ์คู่ขนานเพิ่มขึ้น - จำนวนคอนเทนเนอร์เพิ่มขึ้น ระบบจะปรับขนาดโดยอัตโนมัติ หากผู้ใช้ไม่เข้าถึงฟังก์ชันนี้ ฟังก์ชันดังกล่าวจะปิดใช้งาน
  5. ผู้ให้บริการตั้งเวลาว่างสำหรับคอนเทนเนอร์ - หากในช่วงเวลานี้ฟังก์ชันไม่ปรากฏในคอนเทนเนอร์ ฟังก์ชั่นนั้นจะถูกทำลาย

วิธีนี้ทำให้เรานำ Serverless มาใช้ได้ทันที เราจะชำระค่าบริการโดยใช้รูปแบบการจ่ายตามการใช้งานและเฉพาะฟังก์ชันที่ใช้งานและเฉพาะเวลาที่ใช้งานเท่านั้น

เพื่อแนะนำนักพัฒนาให้รู้จักกับบริการนี้ ผู้ให้บริการเสนอการทดสอบฟรีสูงสุด 12 เดือน แต่จะจำกัดเวลาในการคำนวณทั้งหมด จำนวนคำขอต่อเดือน เงินทุน หรือการใช้พลังงาน

ข้อได้เปรียบหลักของการทำงานกับผู้ให้บริการคือความสามารถในการไม่ต้องกังวลเกี่ยวกับโครงสร้างพื้นฐาน (เซิร์ฟเวอร์ เครื่องเสมือน คอนเทนเนอร์) ในส่วนของผู้ให้บริการสามารถนำ FaaS ไปใช้ทั้งโดยใช้การพัฒนาของตนเองและใช้เครื่องมือโอเพ่นซอร์ส มาพูดคุยเกี่ยวกับพวกเขาเพิ่มเติม

จากฝั่งโอเพ่นซอร์ส

ชุมชนโอเพ่นซอร์สทำงานอย่างแข็งขันเกี่ยวกับเครื่องมือ Serverless ในช่วงสองสามปีที่ผ่านมา ผู้เล่นในตลาดรายใหญ่ที่สุดยังมีส่วนร่วมในการพัฒนาแพลตฟอร์มแบบไร้เซิร์ฟเวอร์:

  • Google นำเสนอเครื่องมือโอเพ่นซอร์สแก่นักพัฒนา - knative. IBM, RedHat, Pivotal และ SAP เข้าร่วมในการพัฒนา
  • ไอบีเอ็ม ทำงานบนแพลตฟอร์มแบบไร้เซิร์ฟเวอร์ เปิดปัดซึ่งต่อมาได้กลายเป็นโครงการของมูลนิธิอาปาเช่
  • ไมโครซอฟท์ เปิดโค้ดแพลตฟอร์มบางส่วน ฟังก์ชัน Azure.

การพัฒนายังดำเนินการไปในทิศทางของเฟรมเวิร์กแบบไร้เซิร์ฟเวอร์ ไม่มีคูเบเลส и การแยก ปรับใช้ภายในคลัสเตอร์ Kubernetes ที่เตรียมไว้ล่วงหน้า OpenFaaS ทำงานร่วมกับทั้ง Kubernetes และ Docker Swarm เฟรมเวิร์กทำหน้าที่เป็นตัวควบคุมชนิดหนึ่ง - เมื่อมีการร้องขอ กรอบงานจะเตรียมสภาพแวดล้อมรันไทม์ภายในคลัสเตอร์ จากนั้นจึงเรียกใช้ฟังก์ชันที่นั่น

เฟรมเวิร์กเหลือพื้นที่สำหรับการกำหนดค่าเครื่องมือให้เหมาะกับความต้องการของคุณ ดังนั้นใน Kubeless นักพัฒนาสามารถกำหนดค่าการหมดเวลาการทำงานของฟังก์ชันได้ (ค่าเริ่มต้นคือ 180 วินาที) ในความพยายามที่จะแก้ปัญหาการสตาร์ทแบบเย็น ฟิชชันแนะนำให้ทำให้คอนเทนเนอร์บางส่วนทำงานอยู่ตลอดเวลา (แม้ว่าจะมีต้นทุนการหยุดทำงานของทรัพยากรก็ตาม) และ OpenFaaS มีชุดทริกเกอร์สำหรับทุกรสนิยมและทุกสี: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs และอื่นๆ

คำแนะนำในการเริ่มต้นสามารถพบได้ในเอกสารอย่างเป็นทางการของเฟรมเวิร์ก การทำงานร่วมกับผู้ให้บริการจำเป็นต้องมีทักษะมากกว่าการทำงานร่วมกับผู้ให้บริการเล็กน้อย - อย่างน้อยที่สุดก็คือความสามารถในการเปิดใช้คลัสเตอร์ Kubernetes ผ่าน CLI อย่างมากที่สุด ให้รวมเครื่องมือโอเพ่นซอร์สอื่นๆ ด้วย (เช่น ตัวจัดการคิวของ Kafka)

ไม่ว่าเราจะทำงานกับ Serverless อย่างไร - ผ่านผู้ให้บริการหรือใช้โอเพ่นซอร์ส เราจะได้รับข้อดีและข้อเสียหลายประการของแนวทางแบบไร้เซิร์ฟเวอร์

จากมุมมองของข้อดีและข้อเสีย

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

Serverless ช่วยลดเวลาในการพัฒนาให้ดียิ่งขึ้นไปอีก ช่วยให้นักพัฒนามุ่งเน้นไปที่ตรรกะทางธุรกิจและการเข้ารหัสของแอปพลิเคชันเพียงอย่างเดียว ส่งผลให้เวลาในการออกสู่ตลาดเพื่อการพัฒนาลดลง

โบนัสคือเราได้รับการปรับขนาดอัตโนมัติสำหรับการโหลด และเราจ่ายเฉพาะทรัพยากรที่ใช้และเฉพาะเวลาที่มีการใช้งานเท่านั้น

เช่นเดียวกับเทคโนโลยีอื่นๆ Serverless ก็มีข้อเสีย

ตัวอย่างเช่นข้อเสียดังกล่าวอาจเป็นเวลาเริ่มต้นแบบเย็น (โดยเฉลี่ยสูงสุด 1 วินาทีสำหรับภาษาเช่น JavaScript, Python, Go, Java, Ruby)

ในด้านหนึ่ง ในความเป็นจริง Cold Start Time ขึ้นอยู่กับตัวแปรหลายอย่าง: ภาษาที่ใช้เขียนฟังก์ชัน จำนวนไลบรารี จำนวนโค้ด การสื่อสารกับทรัพยากรเพิ่มเติม (ฐานข้อมูลเดียวกันหรือเซิร์ฟเวอร์การตรวจสอบความถูกต้อง) เนื่องจากนักพัฒนาควบคุมตัวแปรเหล่านี้ เขาจึงสามารถลดเวลาเริ่มต้นได้ แต่ในทางกลับกัน นักพัฒนาไม่สามารถควบคุมเวลาเริ่มต้นของคอนเทนเนอร์ได้ ทุกอย่างขึ้นอยู่กับผู้ให้บริการ

การสตาร์ทแบบเย็นสามารถเปลี่ยนเป็นการเริ่มต้นแบบอุ่นได้เมื่อฟังก์ชันนำคอนเทนเนอร์ที่เปิดใช้งานโดยเหตุการณ์ก่อนหน้ากลับมาใช้ใหม่ สถานการณ์นี้จะเกิดขึ้นในสามกรณี:

  • หากลูกค้าใช้บริการบ่อยครั้งและจำนวนการโทรไปยังฟังก์ชันเพิ่มขึ้น
  • หากผู้ให้บริการ แพลตฟอร์ม หรือเฟรมเวิร์กอนุญาตให้คุณทำให้คอนเทนเนอร์บางตัวทำงานอยู่ตลอดเวลา
  • หากนักพัฒนารันฟังก์ชันบนตัวจับเวลา (พูดทุกๆ 3 นาที)

สำหรับหลายๆ แอปพลิเคชัน การสตาร์ทขณะเครื่องเย็นไม่ใช่ปัญหา ที่นี่คุณต้องสร้างประเภทและงานของบริการ ความล่าช้าในการเริ่มต้นวินาทีนั้นไม่สำคัญเสมอไปสำหรับแอปพลิเคชันทางธุรกิจ แต่อาจกลายเป็นสิ่งสำคัญสำหรับบริการทางการแพทย์ได้ ในกรณีนี้ วิธีการแบบไร้เซิร์ฟเวอร์อาจจะไม่เหมาะสมอีกต่อไป

ข้อเสียประการถัดไปของ Serverless คืออายุการใช้งานที่สั้นของฟังก์ชัน (หมดเวลาในระหว่างที่ต้องเรียกใช้ฟังก์ชัน)

แต่หากคุณต้องทำงานกับงานที่ใช้เวลานาน คุณสามารถใช้สถาปัตยกรรมไฮบริด - รวม Serverless เข้ากับเทคโนโลยีอื่นได้

ไม่ใช่ทุกระบบที่จะสามารถทำงานได้โดยใช้รูปแบบ Serverless

แอปพลิเคชันบางตัวจะยังคงจัดเก็บข้อมูลและสถานะระหว่างการดำเนินการ สถาปัตยกรรมบางส่วนจะยังคงเป็นเสาหินและคุณลักษณะบางอย่างจะมีอายุการใช้งานยาวนาน อย่างไรก็ตาม (เช่นเดียวกับเทคโนโลยีคลาวด์และคอนเทนเนอร์) Serverless เป็นเทคโนโลยีที่มีอนาคตที่ดี

ในแนวทางนี้ ฉันอยากจะพูดถึงประเด็นของการใช้วิธีการแบบไร้เซิร์ฟเวอร์ได้อย่างราบรื่น

จากด้านแอปพลิเคชัน

สำหรับปี 2018 เปอร์เซ็นต์การใช้งานแบบไร้เซิร์ฟเวอร์ เติบโตหนึ่งเท่าครึ่ง. ในบรรดาบริษัทที่ได้นำเทคโนโลยีนี้ไปใช้ในบริการของตนแล้ว ได้แก่ บริษัทยักษ์ใหญ่ในตลาด เช่น Twitter, PayPal, Netflix, T-Mobile, Coca-Cola ในเวลาเดียวกัน คุณต้องเข้าใจว่า Serverless ไม่ใช่ยาครอบจักรวาล แต่เป็นเครื่องมือในการแก้ปัญหาบางช่วง:

  • ลดการหยุดทำงานของทรัพยากร ไม่จำเป็นต้องเก็บเครื่องเสมือนไว้อย่างต่อเนื่องสำหรับบริการที่มีการโทรน้อย
  • ประมวลผลข้อมูลได้ทันที บีบอัดรูปภาพ ตัดพื้นหลัง เปลี่ยนการเข้ารหัสวิดีโอ ทำงานร่วมกับเซ็นเซอร์ IoT ดำเนินการทางคณิตศาสตร์
  • “กาว”บริการอื่นๆ เข้าด้วยกัน พื้นที่เก็บข้อมูล Git พร้อมโปรแกรมภายใน แชทบอทใน Slack พร้อม Jira และปฏิทิน
  • ปรับสมดุลภาระ มาดูที่นี่กันดีกว่า

สมมติว่ามีบริการที่ดึงดูดคนได้ 50 คน ข้างใต้นั้นมีเครื่องเสมือนพร้อมฮาร์ดแวร์ที่อ่อนแอ ในบางครั้งภาระในบริการจะเพิ่มขึ้นอย่างมาก ฮาร์ดแวร์ที่อ่อนแอก็ไม่สามารถรับมือได้

คุณสามารถรวมบาลานเซอร์ในระบบที่จะกระจายโหลด เช่น เครื่องเสมือนสามเครื่อง ในขั้นตอนนี้ เราไม่สามารถคาดการณ์ปริมาณงานได้อย่างแม่นยำ ดังนั้นเราจึงเก็บทรัพยากรจำนวนหนึ่งไว้ "สำรองไว้" และเราจ่ายเงินมากเกินไปสำหรับการหยุดทำงาน

ในสถานการณ์เช่นนี้ เราสามารถปรับระบบให้เหมาะสมโดยใช้แนวทางแบบไฮบริด: เราทิ้งเครื่องเสมือนไว้ข้างหลังโหลดบาลานเซอร์และใส่ลิงก์ไปยังจุดสิ้นสุดแบบไร้เซิร์ฟเวอร์พร้อมฟังก์ชันต่างๆ หากโหลดเกินขีดจำกัด บาลานเซอร์จะเปิดอินสแตนซ์ฟังก์ชันที่เข้ามาเป็นส่วนหนึ่งของการประมวลผลคำขอ

ไร้เซิร์ฟเวอร์บนชั้นวาง
ดังนั้น Serverless จึงสามารถใช้งานได้เมื่อจำเป็นต้องประมวลผลคำขอจำนวนมากไม่บ่อยเกินไป แต่เข้มข้น ในกรณีนี้ การใช้งานหลายฟังก์ชันเป็นเวลา 15 นาทีจะให้ผลกำไรมากกว่าการดูแลเครื่องเสมือนหรือเซิร์ฟเวอร์ตลอดเวลา

ด้วยข้อดีทั้งหมดของการประมวลผลแบบไร้เซิร์ฟเวอร์ ก่อนที่จะนำไปใช้ คุณควรประเมินตรรกะของแอปพลิเคชันก่อน และทำความเข้าใจว่าปัญหาใดที่ Serverless สามารถแก้ไขได้ในบางกรณี

ไร้เซิร์ฟเวอร์และ Selectel

ที่ Selectel เราก็พร้อมแล้ว ทำงานง่ายขึ้นด้วย Kubernetes ผ่านแผงควบคุมของเรา ตอนนี้เรากำลังสร้างแพลตฟอร์ม FaaS ของเราเอง เราต้องการให้นักพัฒนาสามารถแก้ไขปัญหาโดยใช้ Serverless ผ่านอินเทอร์เฟซที่สะดวกและยืดหยุ่น

หากคุณมีไอเดียว่าแพลตฟอร์ม FaaS ในอุดมคติควรเป็นอย่างไร และคุณต้องการใช้ Serverless ในโปรเจ็กต์ของคุณอย่างไร แบ่งปันความคิดเห็นเหล่านั้นได้ในความคิดเห็น เราจะคำนึงถึงความปรารถนาของคุณเมื่อพัฒนาแพลตฟอร์ม
 
วัสดุที่ใช้ในบทความ:

ที่มา: will.com

เพิ่มความคิดเห็น