เราเคยประสบปัญหาที่น่าสนใจเมื่อไม่กี่ปีที่ผ่านมา เราเป็นบริษัทที่ทำงานจากระยะไกลอย่างเต็มรูปแบบ โดยใช้ซอฟต์แวร์ทั้งหมดบนระบบคลาวด์ และเรามีชุดแอปพลิเคชัน Spring Boot ที่ทำงานบนคอนเทนเนอร์โดยใช้ Infrastructure as Code แต่เราต้องการความคล่องตัวทางธุรกิจ ตลาดแรงงานทั่วโลกเปลี่ยนแปลงอย่างรวดเร็ว และมีความต้องการผลิตภัณฑ์ใหม่ๆ อยู่เสมอ เราต้องหาวิธีรักษาความเป็นผู้นำในอุตสาหกรรมนี้ไว้ให้ได้
เราเป็นบริษัทเทคโนโลยีที่มีกลยุทธ์ที่กล้าหาญ
ใน 2022 เราได้สร้าง ADR (Architecture Decision Record) ที่ระบุว่า "serverless-first และ containers-as-needed" และจุดประกายการถกเถียงในทีมวิศวกรรมเกือบ 40 ทีม
ก่อนอื่นเรามาอธิบายคำศัพท์บางคำกันก่อน
Serverless-first ไม่ได้หมายถึงแค่ฟังก์ชันในรูปแบบบริการ (functions-as-a-service) เท่านั้น แต่ยังหมายถึงกลุ่มบริการจัดการจากผู้ให้บริการคลาวด์ที่:
- ลดต้นทุนการดำเนินงานโดยไม่ต้องบริหารจัดการโครงสร้างพื้นฐาน
- ปรับขนาดได้ตามต้องการ รวมถึงการปรับขนาดให้เป็นศูนย์เพื่อให้มีความยืดหยุ่นอย่างเต็มที่
- ใช้ระบบราคาแบบยืดหยุ่น (จ่ายเฉพาะส่วนที่คุณใช้จริง)
ที่ G-P แนวคิด serverless-first หมายถึงการที่เราใช้ AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, ส่วนต่อประสานโปรแกรมประยุกต์ Gateway, S3, DynamoDB และอื่นๆ
แนวคิด Serverless-first หมายความว่า เมื่อเราเลือกโซลูชันสำหรับการประมวลผล การจัดเก็บข้อมูล การส่งข้อความ หรืออื่นๆ ที่คล้ายกัน เราต้องการให้ทีมเริ่มต้นด้วยตัวเลือกแบบ Serverless ข้อสำคัญ: หากบริการแบบไร้เซิร์ฟเวอร์ไม่ตรงตามความต้องการ ทีมควรเปลี่ยนไปใช้บริการที่มีประสิทธิภาพสูงกว่า ซึ่งต้องใช้การลงทุนด้านการดำเนินงานมากกว่า
“คอนเทนเนอร์ตามความจำเป็น” ชี้แจงว่า เซิร์ฟเวอร์เลสเบิร์ฟเวอร์ก่อน ไม่ได้หมายถึงแบบไร้เซิร์ฟเวอร์เท่านั้น มีบางครั้งที่เราต้องการคอนเทนเนอร์ (เช่น การติดตั้ง ผลิตภัณฑ์ซอฟต์แวร์ COTS) - และไม่เป็นไร
กลยุทธ์ด้านเทคโนโลยีที่ให้ความสำคัญกับลูกค้าเป็นอันดับแรก
เราดำเนินการอย่างรวดเร็วและคล่องตัวเพื่อตอบสนองความต้องการของลูกค้าและผู้ใช้งานของเรา บริการต่างๆ เช่น Lambda, S3 และ DynamoBD มีความยืดหยุ่นและรวดเร็วอย่างเหลือเชื่อ ด้วยการถ่ายโอนงานที่ซ้ำซ้อนและไม่แตกต่างกันออกไป เราจึงสามารถใช้เวลามากขึ้นในการสร้างฟีเจอร์สำหรับผู้ใช้ แทนที่จะเสียเวลาไปกับการกำหนดค่าโครงสร้างพื้นฐานทั่วไป
หลักการสำคัญของ G-P คือ "คุณสร้างมันขึ้นมา คุณก็ต้องบริหารมัน" ทีมของเราเป็นเจ้าของซอฟต์แวร์ของตนเอง ดังนั้น เราไม่ได้แค่โยนซอฟต์แวร์ข้ามกำแพงไปให้ทีม DevOps เท่านั้น
ข้อดีของ “การออกแบบโดยใช้เซิร์ฟเวอร์less เป็นหลัก”
สถาปัตยกรรมแบบ Serverless นั้นขับเคลื่อนด้วยเหตุการณ์โดยเนื้อแท้
สถาปัตยกรรมของเราทำงานโดยอาศัยเหตุการณ์เป็นตัวขับเคลื่อนอย่างสมบูรณ์ ด้วยการใช้ EDA (Event-Driven Architecture) เราสามารถขยายขนาดทั้งองค์กรและซอฟต์แวร์ของเราได้ Serverless บังคับให้เราต้องจำกัดขอบเขตผลกระทบให้แคบลง และสื่อสารกันในรูปแบบคลาวด์เนทีฟอย่างเต็มรูปแบบผ่านทางเหตุการณ์ต่างๆ
ข้อจำกัดที่เอื้ออำนวย
ในฐานะแพลตฟอร์มการจ้างงานทั่วโลก เราให้ ความสำคัญกับกฎระเบียบ อย่างจริงจัง โครงสร้างพื้นฐานระบบคลาวด์ของเราได้รับการออกแบบอย่างดี และเราใช้กลยุทธ์แบบหลายบัญชีที่แยกปริมาณงานและทำให้ระบบคลาวด์เป็นแบบอัตโนมัติตามกฎหมาย Serverless ช่วยให้เราบังคับใช้มาตรฐานสูงโดยควบคุมวิธีที่เราจัดหาทรัพยากรคลาวด์
มอบหมายงานให้ผู้อื่น
ผู้ให้บริการคลาวด์ของเราเป็นผู้ดูแลจัดการบริการเซิร์ฟเวอร์เลสของเรา ชุดส่วนประกอบพื้นฐานเพียงชุดเดียว — ที่ผสานรวม รักษาความปลอดภัย ปรับแต่ง เปิดใช้งาน และบำรุงรักษาโดย AWS — ช่วยให้เราสามารถมุ่งเน้นไปที่การสร้างมูลค่าเพิ่มให้กับลูกค้าได้มากขึ้น
เวิร์กโหลดที่มีโครงสร้างที่ดี
ทุกเวิร์กโหลดที่เราสร้างขึ้นจะได้รับการตรวจสอบโดยใช้กรอบการทำงาน AWS Well-Architected Framework เราให้ความสำคัญกับขนาด ความปลอดภัย ความน่าเชื่อถือ และการเพิ่มประสิทธิภาพด้านต้นทุน เพื่อให้มั่นใจว่าเราไม่เพียงแต่จะปฏิบัติตาม แต่ยังเหนือกว่าข้อตกลงระดับบริการ (SLA) ของเราด้วย สิ่งนี้ช่วยเสริมศักยภาพให้กับทีมวิศวกรรมของเรา ในขณะที่เราพัฒนาอย่างต่อเนื่องไปพร้อมกับสภาพแวดล้อมคลาวด์
เกี่ยวกับทีมงานของเรา
กลยุทธ์ด้านเทคโนโลยีของเรามีความทะเยอทะยาน และนั่นทำให้มันมีความท้าทาย วิศวกรหลายคนยังไม่เคยทำงานในสถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ (หรือสถาปัตยกรรมแบบกระจายศูนย์) มาก่อน การเปลี่ยนไปใช้สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์นั้นไม่ใช่เรื่องง่าย และเรามองหาวิศวกรที่พร้อมเรียนรู้ คิดการณ์ไกล และปรับตัวได้อย่างรวดเร็ว
วิศวกรบางคนไม่แน่ใจเกี่ยวกับคำว่า "เซิร์ฟเวอร์เลส" (ใช่ เราทราบว่ามีเซิร์ฟเวอร์อยู่) เพราะแนวทางนี้ไม่ใช่แค่การเขียนโค้ดในรูปแบบฟังก์ชันเท่านั้น กลยุทธ์ของเราต้องการแนวทางแบบองค์รวมในการปฏิบัติตามหลักการพื้นฐานของคลาวด์เนทีฟ
ผลลัพธ์
เราได้ก้าวหน้าอย่างพิเศษในสองปี การปรับปรุงให้ทันสมัยมีประโยชน์มากมาย (ดูบทความของเราเกี่ยวกับ สกุลเงินโบนัสภาคบังคับ / มูลค่าทางธุรกิจที่ทราบของการปรับให้ทันสมัยบนคลาวด์) โดยเฉพาะเราได้สังเกตสิ่งต่อไปนี้:
1. ความเร็ ว: วิธีที่เราแบ่งระบบของเราทำให้ทีมและผลิตภัณฑ์สามารถสร้างสรรค์นวัตกรรมและพัฒนาได้อย่างอิสระ สิ่งนี้มีผลกระทบอย่างมากต่อความคล่องตัวของธุรกิจ
2. การปฏิบัติตามข้อกำหนด: เราใช้เงินโบนัสภาคบังคับ Well-Architected Framework เพื่อตรวจสอบปริมาณงานทั้งหมด เนื่องจากเราใช้โบนัสภาคบังคับ Managed Services จำนวนมาก เราจึงสามารถไว้วางใจในความเป็นเลิศในการปฏิบัติงานและเริ่มต้นจากสถานที่ที่มีคุณภาพสูง
3. การคิดระบ บ: เราต้องสร้างมาตรฐานกระบวนการหลายอย่างของเราเพื่อให้เราสามารถเหตุผลเกี่ยวกับระบบ ความน่าเชื่อถือ และมูลค่าทางธุรกิจ เราไม่ใช้เวลาทำงานกับส่วนประกอบที่มีมูลค่าต่ำ
4. นวัตกรรม: Serverless หมายถึงทุกสิ่งทุกอย่างเป็นส่วนต่อประสานของผู้คน ข้อจำกัดที่บังคับนี้ต้องใช้แนวทางการดำเนินการเป็นอันดับแรก เมื่อเรามองตัวเองในฐานะแพลตฟอร์ม เราจะสามารถก้าวไปสู่ระดับนวัตกรรมใหม่ได้โดยการเชื่อมต่อระบบต่างๆ ได้อย่างง่ายดายผ่าน API เช่น การเชื่อมต่อ G-P Gia™ เข้ากับฐานความรู้ใหม่
5. กรรมสิทธิ์: โบนัสภาคบังคับเป็นเจ้าของโครงสร้างพื้นฐานของเรา แต่เราเป็นเจ้าของโดเมนธุรกิจของเรา เซิร์ฟเวอร์เบิร์ฟเวอร์FIRST ด้วยการออกแบบที่ขับเคลื่อนด้วยโดเมนทำให้เราต้องมุ่งเน้นไปที่ปัญหาทางธุรกิจ สิ่งนี้ทำให้เจ้าของความสามารถชัดเจน
การออกแบบระบบแบบ Serverless-first ไม่ได้เร็วกว่าเสมอไป แต่มีประโยชน์มากกว่า เราให้ความสำคัญกับความเร็วของระบบมากกว่าความเร็วของนักพัฒนาแต่ละคน แนวคิด Serverless-first ไม่ได้เน้นการใช้ฟังก์ชันมากนัก แต่เน้นความคิดที่ว่า “โค้ดคือภาระ” ระบบนี้คือสินทรัพย์” ยิ่งเราเขียนโค้ดน้อยลงเท่าไหร่ เราก็ยิ่งมีเวลาพิจารณาและปรับแต่งระบบธุรกิจที่เรากำลังสร้างมากขึ้นเท่านั้น
เมื่อเราเล่าเรื่องราวของเราให้ฟัง คุณจะเห็นได้อย่างชัดเจนถึงความเร็วในการทำงานของเรา ซึ่งเป็นผลโดยตรงจากแนวคิด serverless-first โปรดติดตามต่อไป
