Satya Nadella ซีอีโอ Microsoft กล่าวในการแถลงผลประกอบการเดือนเมษายน 2026 ว่า GitHub กำลังเผชิญ “การเติบโตที่ไม่เคยเกิดขึ้นมาก่อน ซึ่งขับเคลื่อนโดยการแพร่หลายของการเขียนโค้ดแบบเอเจนต์” พร้อมระบุว่าบริษัทกำลังเร่งขยายระบบเพื่อรองรับความต้องการดังกล่าว

ก่อนหน้านั้น Vlad Fedorov ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ GitHub ก็ออกคำขอโทษต่อสาธารณะ โดยยอมรับว่าบริษัทประเมินความต้องการด้านกำลังรองรับต่ำเกินไป และช่วงเวลาการทำงานของระบบในเดือนเมษายนลดลงต่ำกว่า 85%

ทำไมต้องเป็น AWS ทั้งที่ Microsoft มี Azure อยู่แล้ว

คำตอบอยู่ที่เวลาและกำลังรองรับที่มีอยู่จริงในขณะนั้น ไม่ใช่การเปลี่ยนใจเชิงยุทธศาสตร์

ทีมโครงสร้างพื้นฐานของ GitHub เคยวางแผนเพิ่มขีดความสามารถของระบบ 10 เท่าในเดือนตุลาคม 2025 แต่ภายในเดือนกุมภาพันธ์ 2026 กลับพบว่าจำเป็นต้องเพิ่มขึ้นถึง 30 เท่า เมื่อปริมาณการใช้งานพุ่งเร็วกว่าการขยายระบบ Microsoft จึงเลือกซื้อกำลังประมวลผลแบบสปอตจาก AWS เพื่อบรรเทาภาระเฉพาะหน้า

โฆษก Microsoft ยืนยันว่า GitHub ใช้ผู้ให้บริการคลาวด์หลายราย แต่ปฏิเสธที่จะให้ความเห็นโดยตรงว่าเกี่ยวข้องกับ Amazon หรือไม่ พร้อมกล่าวว่า “การเพิ่มขึ้นอย่างน่าทึ่งของการพัฒนาแบบเอเจนต์ซึ่งเริ่มขึ้นในช่วงปลายปีที่แล้ว ได้ทดสอบขีดความสามารถของโครงสร้างพื้นฐานของเรา”

กล่าวอีกอย่างคือ Microsoft ต้องการพื้นที่หายใจให้ GitHub ในทันที ขณะที่การเพิ่มกำลังรองรับบน Azure หรือการย้ายระบบส่วนหลักยังต้องใช้เวลา การพึ่ง AWS จึงเป็นการแก้ปัญหาเฉพาะหน้าเพื่อไม่ให้เหตุขัดข้องลุกลาม ไม่ใช่การยกเลิกแผน Azure

แผนย้าย GitHub ไป Azure ยังอยู่ตรงไหน

Microsoft ซื้อ GitHub ด้วยมูลค่า 7,500 ล้านดอลลาร์ในปี 2018 โดยมีเป้าหมายสำคัญประการหนึ่งคือการเชื่อม GitHub เข้ากับ Azure และเสริมการแข่งขันกับ AWS ในตลาดคลาวด์

อย่างไรก็ตาม การย้ายระบบเป็นโครงการหลายปีและยังไม่เสร็จสมบูรณ์

• บริการ CI/CD ของ GitHub หรือ Actions และโมเดลของ Copilot ถูกย้ายไป Azure ในปี 2024
• บริการ Pages และ Packages ตามมาในปี 2025
• ส่วนแพลตฟอร์มหลักและฐานข้อมูลเพิ่งเริ่มย้ายในเดือนตุลาคม 2025
• ณ เดือนกุมภาพันธ์ 2026 มีทราฟฟิกของ GitHub เพียง 12.5% ที่วิ่งผ่าน Azure โดยตั้งเป้าเพิ่มเป็น 50% ภายในเดือนกรกฎาคม 2026

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

การเพิ่มกำลังจาก AWS ยังบ่งชี้ว่า Azure อาจไม่มีทรัพยากรที่พร้อมใช้งานในภูมิภาคที่ต้องการ หรือไม่สามารถจัดสรรกำลังประมวลผลได้เร็วพอที่จะหยุดปัญหาในระยะสั้น สำหรับบริษัทที่วาง Azure ไว้เป็นปลายทางหลัก นี่ถือเป็นการยอมรับข้อจำกัดด้านปฏิบัติการที่มีนัยสำคัญ

การรับมือไม่ได้มีแค่การเช่าเซิร์ฟเวอร์

นอกจากการเพิ่มกำลังจาก AWS แล้ว GitHub และ Microsoft ยังปรับแนวทางการดำเนินงานหลายด้านเพื่อแก้ปัญหาที่ต้นเหตุ

1. กลายเป็นระบบหลายคลาวด์โดยพฤตินัย GitHub กำลังใช้ AWS เป็นชั้นรองรับการใช้งานที่พุ่งสูงแบบฉุกเฉิน ขณะที่การย้ายไป Azure ยังคงดำเนินต่อไป โครงสร้างแบบนี้เป็นการตัดสินใจเชิงปฏิบัติการภายใต้แรงกดดัน มากกว่าจะเป็นการประกาศเปลี่ยนยุทธศาสตร์ระยะยาว
2. เร่งเครื่องมือสำหรับการย้ายระบบ Microsoft เปิดตัวตัวอย่าง Enterprise Live Migrations หรือ ELM บนฝั่ง Azure DevOps เครื่องมือนี้ช่วยย้ายหลาย repository โดยลดเวลาที่ต้องหยุดระบบระหว่างการเปลี่ยนผ่าน สะท้อนว่าบริษัทกำลังยกระดับเครื่องมือย้ายระบบให้รองรับงานขนาดใหญ่ขึ้น
3. จัดลำดับความสำคัญภายในใหม่ รายงานก่อนหน้านี้ระบุว่า GitHub ระงับการพัฒนาฟีเจอร์ใหม่ส่วนใหญ่ชั่วคราว เพื่อมุ่งเน้นการย้ายโครงสร้างพื้นฐานหลักไป Azure ซึ่งถูกมองว่าเป็นภารกิจระดับ “อยู่รอด” หลังศูนย์ข้อมูลในเวอร์จิเนียเข้าใกล้ขีดจำกัดด้านกำลังรองรับ

บทเรียนใหญ่ของวิกฤตครั้งนี้

การที่ Microsoft ต้องซื้อกำลังประมวลผลจาก AWS ไม่ได้หมายความว่า Microsoft กำลังทอดทิ้ง Azure สำหรับ GitHub แต่สะท้อนว่าอัตราการเติบโตของงานที่สร้างโดยเอเจนต์ AI แซงหน้าทั้งแผนขยายระบบและแผนย้ายศูนย์ข้อมูลที่วางไว้ก่อนหน้านี้

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

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

Satya Nadella ซีอีโอ Microsoft กล่าวในการแถลงผลประกอบการเดือนเมษายน 2026 ว่า GitHub กำลังเผชิญ “การเติบโตที่ไม่เคยเกิดขึ้นมาก่อน ซึ่งขับเคลื่อนโดยการแพร่หลายของการเขียนโค้ดแบบเอเจนต์” พร้อมระบุว่าบริษัทกำลังเร่งขยายระบบเพื่อรองรับความต้องการดังกล่าว

ก่อนหน้านั้น Vlad Fedorov ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ GitHub ก็ออกคำขอโทษต่อสาธารณะ โดยยอมรับว่าบริษัทประเมินความต้องการด้านกำลังรองรับต่ำเกินไป และช่วงเวลาการทำงานของระบบในเดือนเมษายนลดลงต่ำกว่า 85%

ทำไมต้องเป็น AWS ทั้งที่ Microsoft มี Azure อยู่แล้ว

คำตอบอยู่ที่เวลาและกำลังรองรับที่มีอยู่จริงในขณะนั้น ไม่ใช่การเปลี่ยนใจเชิงยุทธศาสตร์

ทีมโครงสร้างพื้นฐานของ GitHub เคยวางแผนเพิ่มขีดความสามารถของระบบ 10 เท่าในเดือนตุลาคม 2025 แต่ภายในเดือนกุมภาพันธ์ 2026 กลับพบว่าจำเป็นต้องเพิ่มขึ้นถึง 30 เท่า เมื่อปริมาณการใช้งานพุ่งเร็วกว่าการขยายระบบ Microsoft จึงเลือกซื้อกำลังประมวลผลแบบสปอตจาก AWS เพื่อบรรเทาภาระเฉพาะหน้า

โฆษก Microsoft ยืนยันว่า GitHub ใช้ผู้ให้บริการคลาวด์หลายราย แต่ปฏิเสธที่จะให้ความเห็นโดยตรงว่าเกี่ยวข้องกับ Amazon หรือไม่ พร้อมกล่าวว่า “การเพิ่มขึ้นอย่างน่าทึ่งของการพัฒนาแบบเอเจนต์ซึ่งเริ่มขึ้นในช่วงปลายปีที่แล้ว ได้ทดสอบขีดความสามารถของโครงสร้างพื้นฐานของเรา”

กล่าวอีกอย่างคือ Microsoft ต้องการพื้นที่หายใจให้ GitHub ในทันที ขณะที่การเพิ่มกำลังรองรับบน Azure หรือการย้ายระบบส่วนหลักยังต้องใช้เวลา การพึ่ง AWS จึงเป็นการแก้ปัญหาเฉพาะหน้าเพื่อไม่ให้เหตุขัดข้องลุกลาม ไม่ใช่การยกเลิกแผน Azure

แผนย้าย GitHub ไป Azure ยังอยู่ตรงไหน

Microsoft ซื้อ GitHub ด้วยมูลค่า 7,500 ล้านดอลลาร์ในปี 2018 โดยมีเป้าหมายสำคัญประการหนึ่งคือการเชื่อม GitHub เข้ากับ Azure และเสริมการแข่งขันกับ AWS ในตลาดคลาวด์

อย่างไรก็ตาม การย้ายระบบเป็นโครงการหลายปีและยังไม่เสร็จสมบูรณ์

• บริการ CI/CD ของ GitHub หรือ Actions และโมเดลของ Copilot ถูกย้ายไป Azure ในปี 2024
• บริการ Pages และ Packages ตามมาในปี 2025
• ส่วนแพลตฟอร์มหลักและฐานข้อมูลเพิ่งเริ่มย้ายในเดือนตุลาคม 2025
• ณ เดือนกุมภาพันธ์ 2026 มีทราฟฟิกของ GitHub เพียง 12.5% ที่วิ่งผ่าน Azure โดยตั้งเป้าเพิ่มเป็น 50% ภายในเดือนกรกฎาคม 2026

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

การเพิ่มกำลังจาก AWS ยังบ่งชี้ว่า Azure อาจไม่มีทรัพยากรที่พร้อมใช้งานในภูมิภาคที่ต้องการ หรือไม่สามารถจัดสรรกำลังประมวลผลได้เร็วพอที่จะหยุดปัญหาในระยะสั้น สำหรับบริษัทที่วาง Azure ไว้เป็นปลายทางหลัก นี่ถือเป็นการยอมรับข้อจำกัดด้านปฏิบัติการที่มีนัยสำคัญ

การรับมือไม่ได้มีแค่การเช่าเซิร์ฟเวอร์

นอกจากการเพิ่มกำลังจาก AWS แล้ว GitHub และ Microsoft ยังปรับแนวทางการดำเนินงานหลายด้านเพื่อแก้ปัญหาที่ต้นเหตุ

1. กลายเป็นระบบหลายคลาวด์โดยพฤตินัย GitHub กำลังใช้ AWS เป็นชั้นรองรับการใช้งานที่พุ่งสูงแบบฉุกเฉิน ขณะที่การย้ายไป Azure ยังคงดำเนินต่อไป โครงสร้างแบบนี้เป็นการตัดสินใจเชิงปฏิบัติการภายใต้แรงกดดัน มากกว่าจะเป็นการประกาศเปลี่ยนยุทธศาสตร์ระยะยาว
2. เร่งเครื่องมือสำหรับการย้ายระบบ Microsoft เปิดตัวตัวอย่าง Enterprise Live Migrations หรือ ELM บนฝั่ง Azure DevOps เครื่องมือนี้ช่วยย้ายหลาย repository โดยลดเวลาที่ต้องหยุดระบบระหว่างการเปลี่ยนผ่าน สะท้อนว่าบริษัทกำลังยกระดับเครื่องมือย้ายระบบให้รองรับงานขนาดใหญ่ขึ้น
3. จัดลำดับความสำคัญภายในใหม่ รายงานก่อนหน้านี้ระบุว่า GitHub ระงับการพัฒนาฟีเจอร์ใหม่ส่วนใหญ่ชั่วคราว เพื่อมุ่งเน้นการย้ายโครงสร้างพื้นฐานหลักไป Azure ซึ่งถูกมองว่าเป็นภารกิจระดับ “อยู่รอด” หลังศูนย์ข้อมูลในเวอร์จิเนียเข้าใกล้ขีดจำกัดด้านกำลังรองรับ

บทเรียนใหญ่ของวิกฤตครั้งนี้

การที่ Microsoft ต้องซื้อกำลังประมวลผลจาก AWS ไม่ได้หมายความว่า Microsoft กำลังทอดทิ้ง Azure สำหรับ GitHub แต่สะท้อนว่าอัตราการเติบโตของงานที่สร้างโดยเอเจนต์ AI แซงหน้าทั้งแผนขยายระบบและแผนย้ายศูนย์ข้อมูลที่วางไว้ก่อนหน้านี้

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

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