คลึชเววอ моменты
- เป็นเวลาหลายปีแล้วที่เราได้รับคำมั่นสัญญาว่าการประมวลผลแบบไร้เซิร์ฟเวอร์ (ไร้เซิร์ฟเวอร์) จะเปิดศักราชใหม่โดยไม่ต้องใช้ระบบปฏิบัติการเฉพาะเพื่อเรียกใช้แอปพลิเคชัน เราได้รับแจ้งว่าโครงสร้างดังกล่าวจะช่วยแก้ปัญหาความสามารถในการปรับขนาดได้มากมาย ในความเป็นจริงทุกอย่างแตกต่างกัน
- แม้ว่าหลายคนจะมองว่าเทคโนโลยีไร้เซิร์ฟเวอร์เป็นแนวคิดใหม่ แต่รากเหง้าของเทคโนโลยีนี้สามารถสืบย้อนไปถึงปี 2006 ด้วย Zimki PaaS และ Google App Engine ซึ่งทั้งสองอย่างนี้ใช้สถาปัตยกรรมไร้เซิร์ฟเวอร์
- มีเหตุผลสี่ประการที่ทำให้การปฏิวัติไร้เซิร์ฟเวอร์หยุดชะงัก ตั้งแต่การรองรับภาษาโปรแกรมที่จำกัดไปจนถึงปัญหาด้านประสิทธิภาพ
- การประมวลผลแบบไร้เซิร์ฟเวอร์ไม่ได้ไร้ประโยชน์ทั้งหมด ไกลจากมัน. อย่างไรก็ตาม ไม่ควรมองว่าเป็นการทดแทนโดยตรงสำหรับเซิร์ฟเวอร์ สำหรับบางแอปพลิเคชัน พวกเขาสามารถเป็นเครื่องมือที่มีประโยชน์
เซิฟเวอร์ล่ม เซิฟเวอร์อยู่ยาว!
นี่คือเสียงเรียกร้องของผู้สนับสนุนการปฏิวัติไร้เซิร์ฟเวอร์ ภาพรวมของข่าวอุตสาหกรรมในช่วงไม่กี่ปีที่ผ่านมาก็เพียงพอแล้วที่จะสรุปได้ว่าโมเดลเซิร์ฟเวอร์แบบดั้งเดิมนั้นตายไปแล้ว และในอีกไม่กี่ปีข้างหน้า เราทุกคนจะใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์
อย่างที่ใคร ๆ ในอุตสาหกรรมรู้ และอย่างที่เราได้กล่าวไปแล้วในบทความของเราเรื่อง นี้เป็นสิ่งที่ผิด แม้จะมีบทความมากมายเกี่ยวกับข้อดี มันไม่เคยเกิดขึ้น ในความเป็นจริง, ว่าการปฏิวัติครั้งนี้อาจถึงทางตัน
คำมั่นสัญญาบางประการสำหรับโมเดลไร้เซิร์ฟเวอร์นั้นเกิดขึ้นจริง แต่ไม่ใช่ทั้งหมด ไม่ใช่ทุกคน
ในบทความนี้ฉันต้องการพิจารณาสาเหตุของเงื่อนไขนี้ เหตุใดโมเดลไร้เซิร์ฟเวอร์ที่ขาดความยืดหยุ่นจึงยังคงเป็นอุปสรรคต่อการนำไปใช้ในวงกว้าง แม้ว่าโมเดลเหล่านี้จะยังคงมีประโยชน์ในสถานการณ์ที่เฉพาะเจาะจงและชัดเจน
สิ่งที่ Adapts ของการประมวลผลแบบไร้เซิร์ฟเวอร์สัญญาไว้
ก่อนที่จะพูดถึงปัญหาของการประมวลผลแบบไร้เซิร์ฟเวอร์ เรามาดูกันว่าพวกเขาต้องเตรียมอะไรบ้าง มีมากมายและบางครั้งก็ทะเยอทะยานมาก
สำหรับผู้ที่ไม่คุ้นเคยกับคำศัพท์ นี่คือคำจำกัดความสั้นๆ การประมวลผลแบบไร้เซิร์ฟเวอร์กำหนดสถาปัตยกรรมที่แอปพลิเคชัน (หรือบางส่วนของแอปพลิเคชัน) ทำงานตามความต้องการในสภาพแวดล้อมรันไทม์ที่โดยทั่วไปโฮสต์จากระยะไกล นอกจากนี้ยังสามารถโฮสต์ระบบไร้เซิร์ฟเวอร์ได้ การสร้างระบบไร้เซิร์ฟเวอร์ที่มีประสิทธิภาพเป็นข้อกังวลหลักของผู้ดูแลระบบและบริษัท SaaS ในช่วงไม่กี่ปีที่ผ่านมา เนื่องจาก (มีการกล่าวอ้าง) สถาปัตยกรรมนี้นำเสนอข้อได้เปรียบที่สำคัญหลายประการเหนือรูปแบบไคลเอนต์/เซิร์ฟเวอร์ "ดั้งเดิม":
- โมเดลไร้เซิร์ฟเวอร์ไม่ต้องการให้ผู้ใช้ดูแลรักษาระบบปฏิบัติการของตนเอง หรือแม้แต่สร้างแอปพลิเคชันที่เข้ากันได้กับระบบปฏิบัติการเฉพาะ แต่นักพัฒนากลับสร้างโค้ดที่ใช้ร่วมกัน อัปโหลดไปยังแพลตฟอร์มไร้เซิร์ฟเวอร์ และเฝ้าดูมันทำงาน
- ทรัพยากรในเฟรมเวิร์กไร้เซิร์ฟเวอร์มักจะเรียกเก็บเงินเป็นนาที (หรือแม้แต่วินาที) ซึ่งหมายความว่าลูกค้าจะจ่ายเฉพาะเวลาที่ใช้โค้ดจริงเท่านั้น สิ่งนี้เปรียบเทียบได้ดีกับ Cloud VM แบบดั้งเดิมที่เครื่องไม่ได้ใช้งานเกือบตลอดเวลา แต่คุณต้องจ่ายเงิน
- ปัญหาของความสามารถในการปรับขนาดก็ได้รับการแก้ไขเช่นกัน ทรัพยากรในเฟรมเวิร์กแบบไร้เซิร์ฟเวอร์ถูกกำหนดแบบไดนามิกเพื่อให้ระบบสามารถรับมือกับความต้องการที่พุ่งสูงขึ้นอย่างรวดเร็วได้อย่างง่ายดาย
กล่าวโดยย่อ โมเดลไร้เซิร์ฟเวอร์ให้โซลูชันที่ยืดหยุ่น ต้นทุนต่ำ และปรับขนาดได้ ฉันประหลาดใจที่เราไม่ได้คิดถึงแนวคิดนี้ก่อนหน้านี้
นี่เป็นแนวคิดใหม่จริงหรือ
จริงๆ แล้วแนวคิดนี้ไม่ใช่เรื่องใหม่ แนวคิดของการอนุญาตให้ผู้ใช้ชำระเงินเฉพาะเวลาที่โค้ดรันจริงมีมาตั้งแต่เปิดตัวภายใต้ ในปี 2006 และในช่วงเวลาเดียวกัน Google App Engine ก็พบโซลูชันที่คล้ายกันมาก
อันที่จริง สิ่งที่เราเรียกว่าโมเดล "ไร้เซิร์ฟเวอร์" ในปัจจุบันนั้นเก่ากว่าเทคโนโลยีหลายอย่างที่ปัจจุบันเรียกว่า "คลาวด์เนทีฟ" ซึ่งให้บริการเกือบจะเหมือนกัน ตามที่ระบุไว้ โมเดลไร้เซิร์ฟเวอร์เป็นเพียงส่วนเสริมของโมเดลธุรกิจ SaaS ที่มีมานานหลายทศวรรษ
นอกจากนี้ยังควรตระหนักว่าโมเดลไร้เซิร์ฟเวอร์ไม่ใช่สถาปัตยกรรม FaaS แม้ว่าทั้งสองจะมีการเชื่อมต่อกัน FaaS เป็นส่วนสำคัญในการประมวลผลของสถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ แต่มันไม่ได้เป็นตัวแทนของระบบทั้งหมด
เหตุใดจึงต้องโฆษณาทั้งหมดนี้ ในขณะที่อัตราการเข้าถึงอินเทอร์เน็ตในประเทศกำลังพัฒนายังคงเพิ่มสูงขึ้นอย่างรวดเร็ว ความต้องการทรัพยากรคอมพิวเตอร์ก็เพิ่มขึ้นเช่นกัน ตัวอย่างเช่น หลายประเทศที่มีภาคส่วนอีคอมเมิร์ซที่เติบโตอย่างรวดเร็วนั้นไม่มีโครงสร้างพื้นฐานด้านคอมพิวเตอร์สำหรับแอปพลิเคชันบนแพลตฟอร์มเหล่านี้ นี่คือที่มาของแพลตฟอร์มแบบไร้เซิร์ฟเวอร์แบบชำระเงิน
ปัญหาเกี่ยวกับโมเดลไร้เซิร์ฟเวอร์
สิ่งที่จับต้องได้คือโมเดลไร้เซิร์ฟเวอร์มีปัญหา... อย่าเข้าใจฉันผิด: ฉันไม่ได้บอกว่าพวกเขาไม่ดีในตัวเองหรือไม่ให้คุณค่าที่สำคัญแก่บางบริษัทในบางสถานการณ์ แต่คำกล่าวอ้างหลักของ "การปฏิวัติ" นั่นคือสถาปัตยกรรมไร้เซิร์ฟเวอร์จะมาแทนที่สถาปัตยกรรมดั้งเดิมอย่างรวดเร็วนั้นไม่เคยบรรลุผล
นั่นเป็นเหตุผล
การสนับสนุนอย่างจำกัดสำหรับภาษาโปรแกรม
แพลตฟอร์มไร้เซิร์ฟเวอร์ส่วนใหญ่อนุญาตให้เรียกใช้แอปพลิเคชันที่เขียนด้วยภาษาบางภาษาเท่านั้น สิ่งนี้จำกัดความยืดหยุ่นและความสามารถในการปรับตัวของระบบเหล่านี้อย่างมาก
แพลตฟอร์มแบบไร้เซิร์ฟเวอร์ได้รับการพิจารณาว่ารองรับภาษาหลักส่วนใหญ่ ฟังก์ชัน AWS Lambda และ Azure ยังมีส่วนรวมสำหรับการเรียกใช้แอปพลิเคชันและฟังก์ชันในภาษาที่ไม่รองรับ แม้ว่าสิ่งนี้มักจะมาพร้อมกับต้นทุนด้านประสิทธิภาพก็ตาม ดังนั้นสำหรับองค์กรส่วนใหญ่ ข้อจำกัดนี้มักจะไม่ใช่เรื่องใหญ่ แต่นี่คือสิ่งที่ ข้อดีอย่างหนึ่งของโมเดลไร้เซิร์ฟเวอร์คือโปรแกรมที่ไม่ชัดเจนและใช้งานไม่บ่อยอาจถูกกว่าเพราะคุณจ่ายเฉพาะเวลาที่รันเท่านั้น และโปรแกรมที่คลุมเครือและไม่ค่อยได้ใช้มักจะเขียนด้วย... ภาษาโปรแกรมที่คลุมเครือและไม่ค่อยได้ใช้
สิ่งนี้บั่นทอนข้อดีหลักอย่างหนึ่งของโมเดลไร้เซิร์ฟเวอร์
ผูกพันกับผู้ขาย
ปัญหาที่สองเกี่ยวกับแพลตฟอร์มแบบไร้เซิร์ฟเวอร์ หรืออย่างน้อยที่สุดก็คือวิธีที่พวกเขาใช้งานอยู่ในปัจจุบัน ก็คือพวกเขามักจะดูไม่เหมือนกันในระดับปฏิบัติการ แทบไม่มีการกำหนดมาตรฐานในแง่ของฟังก์ชันการเขียน การปรับใช้ และการจัดการ ซึ่งหมายความว่าการย้ายฟีเจอร์จากแพลตฟอร์มหนึ่งไปยังอีกแพลตฟอร์มหนึ่งนั้นใช้เวลานานมาก
ส่วนที่ยากที่สุดในการย้ายไปยังโมเดลไร้เซิร์ฟเวอร์ไม่ใช่ฟีเจอร์การคำนวณ ซึ่งมักจะเป็นเพียงส่วนย่อยของโค้ด แต่เป็นวิธีที่แอปพลิเคชันสื่อสารกับระบบที่เชื่อมต่อ เช่น พื้นที่จัดเก็บออบเจกต์ การจัดการข้อมูลประจำตัว และคิว สามารถย้ายฟังก์ชันได้ แต่แอปพลิเคชันที่เหลือไม่สามารถทำได้ สิ่งนี้ตรงกันข้ามกับแพลตฟอร์มราคาถูกและยืดหยุ่นที่สัญญาไว้
บางคนโต้แย้งว่าโมเดลไร้เซิร์ฟเวอร์นั้นใหม่และยังไม่มีเวลาที่จะสร้างมาตรฐานวิธีการทำงาน แต่ไม่ใช่เรื่องใหม่ดังที่ฉันได้กล่าวไว้ข้างต้น และเทคโนโลยีคลาวด์อื่น ๆ อีกมากมาย เช่น คอนเทนเนอร์ ได้กลายเป็นสิ่งที่สะดวกขึ้นมากแล้ว เนื่องจากการพัฒนาและการนำมาตรฐานที่ดีมาใช้อย่างแพร่หลาย
การปฏิบัติ
ประสิทธิภาพการประมวลผลของแพลตฟอร์มไร้เซิร์ฟเวอร์นั้นวัดได้ยาก ส่วนหนึ่งเป็นเพราะผู้ขายมักจะเก็บข้อมูลเป็นความลับ ส่วนใหญ่ให้เหตุผลว่าคุณสมบัติบนแพลตฟอร์มระยะไกลแบบไร้เซิร์ฟเวอร์ทำงานได้เร็วพอๆ กับที่ทำงานบนเซิร์ฟเวอร์ภายใน ประหยัดสำหรับปัญหาด้านเวลาแฝงที่หลีกเลี่ยงไม่ได้
อย่างไรก็ตาม หลักฐานบางอย่างแสดงให้เห็นเป็นอย่างอื่น ฟังก์ชันที่ไม่เคยรันบนแพลตฟอร์มใดแพลตฟอร์มหนึ่งมาก่อน หรือไม่ได้รันมาระยะหนึ่งแล้ว ต้องใช้เวลาในการเริ่มต้น อาจเป็นเพราะรหัสของพวกเขาได้รับการพอร์ตไปยังสื่อเก็บข้อมูลที่พร้อมใช้งานน้อย แม้ว่าผู้ขายส่วนใหญ่จะไม่แจ้งให้คุณทราบเกี่ยวกับการพอร์ตข้อมูล เช่นเดียวกับเกณฑ์มาตรฐาน
แน่นอนว่ามีหลายวิธีในการแก้ไขปัญหานี้ หนึ่งคือการปรับคุณสมบัติให้เหมาะสมสำหรับภาษาคลาวด์ใดก็ตามที่แพลตฟอร์มไร้เซิร์ฟเวอร์ของคุณทำงาน แต่นั่นค่อนข้างทำลายการอ้างว่าแพลตฟอร์มเหล่านี้ "คล่องตัว"
อีกวิธีหนึ่งคือเพื่อให้แน่ใจว่าโปรแกรมที่เน้นประสิทธิภาพทำงานเป็นประจำเพื่อให้โปรแกรมเหล่านั้น "ใหม่" แน่นอนว่าแนวทางที่สองนี้สวนทางกับคำกล่าวอ้างที่ว่าแพลตฟอร์มแบบไร้เซิร์ฟเวอร์มีความคุ้มค่ามากกว่า เนื่องจากคุณจ่ายเฉพาะเวลาที่โปรแกรมของคุณทำงานเท่านั้น ผู้ให้บริการระบบคลาวด์ได้แนะนำวิธีใหม่ๆ ในการลดการเริ่มต้นเย็น แต่หลายๆ วิธีต้องการ "ปรับขนาดเป็นหนึ่ง" (ปรับขนาดเป็นหนึ่ง) ซึ่งทำลายคุณค่าดั้งเดิมของ FaaS
ปัญหาการเริ่มเย็นสามารถแก้ไขได้บางส่วนโดยการใช้ระบบไร้เซิร์ฟเวอร์ภายในองค์กร แต่สิ่งนี้ต้องเสียค่าใช้จ่ายเองและยังคงเป็นตัวเลือกเฉพาะสำหรับทีมที่มีทรัพยากรที่ดี
คุณไม่สามารถเรียกใช้แอปพลิเคชันทั้งหมดได้
สุดท้าย บางทีเหตุผลที่สำคัญที่สุดว่าทำไมสถาปัตยกรรมแบบไร้เซิร์ฟเวอร์จึงไม่สามารถแทนที่โมเดลดั้งเดิมได้ในเร็วๆ นี้ก็คือ พวกเขา (โดยทั่วไป) ไม่สามารถเรียกใช้แอปพลิเคชันทั้งหมดได้
อย่างแม่นยำกว่านั้นไม่สามารถทำได้จากมุมมองของต้นทุน เสาหินที่ประสบความสำเร็จของคุณไม่น่าจะกลายเป็นชุดของฟังก์ชันสี่โหลที่เชื่อมโยงกันด้วยแปดเกตเวย์ สี่สิบคิว และอินสแตนซ์ฐานข้อมูลโหล ด้วยเหตุผลนี้ เซิร์ฟเวอร์แบบไร้เซิร์ฟเวอร์จึงเหมาะสมกว่าสำหรับการพัฒนาใหม่ แทบจะไม่สามารถพอร์ตแอปพลิเคชัน (สถาปัตยกรรม) ที่มีอยู่ได้ คุณสามารถย้ายข้อมูลได้ แต่คุณต้องเริ่มต้นใหม่ทั้งหมด
ซึ่งหมายความว่าในกรณีส่วนใหญ่ แพลตฟอร์มแบบไร้เซิร์ฟเวอร์จะถูกใช้เป็นส่วนเสริมของเซิร์ฟเวอร์ส่วนหลังเพื่อทำงานที่ต้องใช้การคำนวณสูง สิ่งนี้แตกต่างอย่างมากจากคลาวด์คอมพิวติ้ง คอนเทนเนอร์ และเวอร์ชวลแมชชีนอีกสองรูปแบบ ซึ่งนำเสนอวิธีการแบบองค์รวมในการประมวลผลระยะไกล สิ่งนี้แสดงให้เห็นถึงความท้าทายประการหนึ่งของการย้ายจากไมโครเซอร์วิสไปสู่ระบบไร้เซิร์ฟเวอร์
แน่นอนว่านี่ไม่ใช่ปัญหาเสมอไป ความสามารถในการใช้ทรัพยากรคอมพิวเตอร์ขนาดใหญ่เป็นระยะโดยไม่ต้องซื้อฮาร์ดแวร์ของคุณเองสามารถก่อให้เกิดประโยชน์ที่แท้จริงและยั่งยืนแก่องค์กรจำนวนมาก แต่ถ้าบางแอปพลิเคชันอยู่บนเซิร์ฟเวอร์ภายในและบางแอปพลิเคชันอยู่บนสถาปัตยกรรมคลาวด์แบบไร้เซิร์ฟเวอร์ การจัดการจะเข้าสู่ระดับใหม่ของความซับซ้อน
การปฏิวัติจงเจริญ?
แม้จะมีการร้องเรียนเหล่านี้ ฉันไม่ได้ต่อต้านวิธีแก้ปัญหาแบบไร้เซิร์ฟเวอร์ สุจริต. นักพัฒนาจำเป็นต้องเข้าใจ - โดยเฉพาะอย่างยิ่งหากพวกเขากำลังสำรวจโมเดลไร้เซิร์ฟเวอร์เป็นครั้งแรก - ว่าเทคโนโลยีนี้ไม่ใช่สิ่งทดแทนโดยตรงสำหรับเซิร์ฟเวอร์ ให้ดูเคล็ดลับและแหล่งข้อมูลของเราแทน และตัดสินใจว่าจะใช้โมเดลนี้อย่างไรให้ดีที่สุด
ที่มา: will.com