เราเคยประสบปัญหาที่น่าสนใจเมื่อไม่กี่ปีที่ผ่านมา เราเป็นบริษัทที่ทำงานจากระยะไกลอย่างเต็มรูปแบบ โดยใช้ซอฟต์แวร์ทั้งหมดบนระบบคลาวด์ และเรามีชุดแอปพลิเคชัน 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 ข้อสำคัญ: หากบริการแบบไร้เซิร์ฟเวอร์ไม่ตรงตามความต้องการ ทีมควรเปลี่ยนไปใช้บริการที่มีประสิทธิภาพสูงกว่า ซึ่งต้องใช้การลงทุนด้านการดำเนินงานมากกว่า

“คอนเทนเนอร์ตามความต้องการ” ชี้แจงว่า แนวคิด “serverless-first” ไม่ได้หมายความว่าต้องใช้ serverless เท่านั้น บางครั้งเราจำเป็นต้องใช้คอนเทนเนอร์ (เช่น การติดตั้ง ซอฟต์แวร์สำเร็จรูป) ซึ่งก็ไม่ใช่เรื่องผิดอะไร

กลยุทธ์ด้านเทคโนโลยีที่ให้ความสำคัญกับลูกค้าเป็นอันดับแรก

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

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

ข้อดีของ “การออกแบบโดยใช้เซิร์ฟเวอร์less เป็นหลัก”

สถาปัตยกรรมแบบ Serverless นั้นขับเคลื่อนด้วยเหตุการณ์โดยเนื้อแท้

สถาปัตยกรรมของเราทำงานโดยอาศัยเหตุการณ์เป็นตัวขับเคลื่อนอย่างสมบูรณ์ ด้วยการใช้ EDA (Event-Driven Architecture) เราสามารถขยายขนาดทั้งองค์กรและซอฟต์แวร์ของเราได้ Serverless บังคับให้เราต้องจำกัดขอบเขตผลกระทบให้แคบลง และสื่อสารกันในรูปแบบคลาวด์เนทีฟอย่างเต็มรูปแบบผ่านทางเหตุการณ์ต่างๆ

ข้อจำกัดที่เอื้ออำนวย

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

มอบหมายงานให้ผู้อื่น

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

เวิร์กโหลดที่มีโครงสร้างที่ดี

ทุกเวิร์กโหลดที่เราสร้างขึ้นจะได้รับการตรวจสอบโดยใช้กรอบการทำงาน AWS Well-Architected Framework เราให้ความสำคัญกับขนาด ความปลอดภัย ความน่าเชื่อถือ และการเพิ่มประสิทธิภาพด้านต้นทุน เพื่อให้มั่นใจว่าเราไม่เพียงแต่จะปฏิบัติตาม แต่ยังเหนือกว่าข้อตกลงระดับบริการ (SLA) ของเราด้วย สิ่งนี้ช่วยเสริมศักยภาพให้กับทีมวิศวกรรมของเรา ในขณะที่เราพัฒนาอย่างต่อเนื่องไปพร้อมกับสภาพแวดล้อมคลาวด์ 

เกี่ยวกับทีมงานของเรา

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

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

ผลลัพธ์

เราประสบความสำเร็จอย่างมากในช่วงสองปีที่ผ่านมา การปรับปรุงระบบให้ทันสมัยมีประโยชน์มากมาย (ดูบทความของเราเกี่ยวกับ AWS / มูลค่าทางธุรกิจที่ทราบกันดีของการปรับปรุงระบบคลาวด์ให้ทันสมัย) โดยเฉพาะอย่างยิ่ง เราได้สังเกตเห็นสิ่งต่อไปนี้:

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

2. การปฏิบัติตามข้อกำหนด: เราใช้ AWS Well-Architected Framework ในการตรวจสอบเวิร์กโหลดทั้งหมด เนื่องจากเราใช้บริการจัดการของ AWS จำนวนมาก เราจึงสามารถวางใจได้ในความเป็นเลิศด้านการดำเนินงานของพวกเขา และเริ่มต้นจากจุดที่มีคุณภาพสูงได้

3. การคิดเชิงระบบ: เราต้องกำหนดมาตรฐานให้กับกระบวนการหลายอย่าง เพื่อให้เราสามารถวิเคราะห์ระบบ ความน่าเชื่อถือ และคุณค่าทางธุรกิจได้ เราไม่เสียเวลาไปกับการพัฒนาชิ้นส่วนที่มีมูลค่าต่ำ

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

5. ความเป็นเจ้าของ: AWS เป็นเจ้าของโครงสร้างพื้นฐานของเรา แต่เราเป็นเจ้าของโดเมนธุรกิจของเรา การวางระบบแบบ Serverless เป็นหลักควบคู่กับการออกแบบที่ขับเคลื่อนด้วยโดเมน ทำให้เราต้องมุ่งเน้นไปที่ปัญหาทางธุรกิจเป็นหลัก วิธีนี้ช่วยให้เห็นชัดเจนถึงความเป็นเจ้าของความสามารถนั้นๆ

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

เมื่อเราเล่าเรื่องราวของเราให้ฟัง คุณจะเห็นได้อย่างชัดเจนถึงความเร็วในการทำงานของเรา ซึ่งเป็นผลโดยตรงจากแนวคิด serverless-first โปรดติดตามต่อไป