ทําไม G-P จึงเลือก Serverless-First

เรามีปัญหาที่น่าสนใจเมื่อไม่กี่ปีที่ผ่านมา เราเป็นบริษัทที่อยู่ห่างไกลออกไปอย่างเต็มที่ด้วยซอฟต์แวร์ทั้งหมดของเราบนระบบคลาวด์ และเรามีชุดแอปพลิเคชัน Spring Boot ที่ทํางานบนคอนเทนเนอร์ที่มีโครงสร้างพื้นฐานเป็นโค้ด แต่เราต้องการความคล่องตัวทางธุรกิจ

ตลาดการจ้างงานทั่วโลกดําเนินไปอย่างรวดเร็ว และมีความต้องการผลิตภัณฑ์ใหม่อยู่เสมอ เราต้องหาวิธีรักษาความเป็นผู้นําของเราทั่วทั้งอุตสาหกรรม

เราเป็นบริษัทเทคโนโลยีที่มีกลยุทธ์ที่โดดเด่น

ในปี ค.ศ. 2022 เราได้สร้าง ADR (บันทึกการตัดสินใจเกี่ยวกับสถาปัตยกรรม) ที่กล่าวว่า "ไร้เซิร์ฟเวอร์และคอนเทนเนอร์ที่จําเป็น" และจุดประกายการอภิปรายในทีมวิศวกรรมเกือบ 40 ทีม

เรามาอธิบายคําศัพท์บางคําก่อน

Serverless-first ไม่ใช่แค่ฟังก์ชันที่เป็นบริการเท่านั้น นอกจากนี้ยังเป็นกลุ่มของบริการที่มีการจัดการจากผู้ให้บริการระบบคลาวด์ที่: 

• ลดค่าใช้จ่ายในการดําเนินงานโดยไม่จัดการโครงสร้างพื้นฐาน

• ปรับขนาดตามต้องการ รวมถึงปรับขนาดให้เป็นศูนย์เพื่อให้มีความยืดหยุ่นเต็มที่

• มีการกําหนดราคาที่ยืดหยุ่น (คุณจ่ายเฉพาะสิ่งที่คุณใช้) 

ที่ G-P ระบบไร้เซิร์ฟเวอร์ หมายถึง การใช้ AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB และอื่น ๆ

Serverless-first หมายความว่าเมื่อเราเลือกโซลูชันสําหรับ Compute, Storage, Messaging หรือที่คล้ายกัน เราต้องการให้ทีมเริ่มต้นด้วยตัวเลือกแบบไร้เซิร์ฟเวอร์ หมายเหตุสําคัญ: หากบริการแบบไร้เซิร์ฟเวอร์ไม่ตอบสนองความต้องการ ทีมควรกลับไปที่บริการที่หนักกว่า ซึ่งต้องใช้การลงทุนในการดําเนินงานมากกว่า

“คอนเทนเนอร์ตามความต้องการ” อธิบายว่าเซิร์ฟเวอร์แบบไร้เซิร์ฟเวอร์ไม่ได้หมายถึงเซิร์ฟเวอร์แบบไร้เซิร์ฟเวอร์เท่านั้น มีหลายครั้งที่เราต้องการตู้คอนเทนเนอร์ (เช่น การติดตั้ง ผลิตภัณฑ์ซอฟต์แวร์ COTS) ซึ่งไม่เป็นไร

กลยุทธ์เทคโนโลยีที่ให้ความสําคัญกับลูกค้า

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

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

ประโยชน์ของ “ความไร้เซิร์ฟเวอร์”

ระบบไร้เซิร์ฟเวอร์ขับเคลื่อนด้วยเหตุการณ์

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

การเปิดใช้งานข้อจํากัด

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

ถ่ายงาน

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

ปริมาณงานที่มีการจัดเก็บอย่างดี

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

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

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

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

ผลลัพธ์

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

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

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

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

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

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

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

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