Starting Again (เริ่มต้นใหม่)

สถาปัตยกรรมที่ทำให้คุณเริ่มต้นได้อาจไม่ใช่สถาปัตยกรรมที่จะพาคุณต่อไปได้เมื่อระบบของคุณต้องรับมือกับปริมาณโหลดที่แตกต่างไปมาก ตามที่เราได้เห็นแล้ว scaling บางรูปแบบสามารถมีผลกระทบที่จำกัดมากต่อสถาปัตยกรรมของระบบคุณ—vertical scaling และ horizontal duplication เป็นต้น แต่ในบางจุด คุณต้องทำอะไรบางอย่างที่ค่อนข้างรุนแรงเพื่อเปลี่ยนสถาปัตยกรรมของระบบคุณ เพื่อรองรับระดับการเติบโตขั้นถัดไป

จำเรื่องราวของ Gilt ที่เราพูดถึงใน "Isolated Execution" ได้ไหม แอปพลิเคชัน Rails แบบ monolithic ง่ายๆ ทำงานได้ดีให้กับ Gilt เป็นเวลาสองปี ธุรกิจของบริษัทประสบความสำเร็จมากขึ้นเรื่อยๆ หมายความว่ามีลูกค้าและโหลดมากขึ้น ที่จุดพลิกผันหนึ่ง บริษัทต้องออกแบบแอปพลิเคชันใหม่เพื่อรับมือกับโหลดที่กำลังเจอ

การออกแบบใหม่อาจหมายถึงการแยกส่วน monolith ที่มีอยู่ออกจากกัน อย่างที่เกิดขึ้นกับ Gilt หรือมันอาจหมายถึงการเลือก data store ใหม่ที่รับมือโหลดได้ดีกว่า มันยังอาจหมายถึงการนำเทคนิคใหม่มาใช้ เช่น การย้ายจาก synchronous request-response ไปสู่ระบบแบบ event-based การนำแพลตฟอร์ม deployment ใหม่มาใช้ การเปลี่ยน technology stack ทั้งหมด หรือทุกอย่างที่อยู่ตรงกลาง

มีอันตรายที่ผู้คนจะเห็นความจำเป็นในการปรับสถาปัตยกรรมใหม่เมื่อ threshold ของ scaling บางอย่างถูกไปถึงว่าเป็นเหตุผลที่จะสร้างสำหรับ scale ขนาดใหญ่ตั้งแต่เริ่มต้น สิ่งนี้อาจกลายเป็นหายนะได้ ในช่วงเริ่มต้นของโปรเจกต์ใหม่ เรามักไม่รู้แน่ชัดว่าเราต้องการสร้างอะไร และเราก็ไม่รู้ว่ามันจะประสบความสำเร็จหรือไม่ เราต้องสามารถทดลองอย่างรวดเร็วและเข้าใจว่าเราต้องสร้างความสามารถอะไรบ้าง ถ้าเราพยายามสร้างสำหรับ scale ขนาดใหญ่ตั้งแต่แรก เรา ก็จะจบลงด้วยการทุ่มงานจำนวนมหาศาลล่วงหน้าเพื่อเตรียมรับโหลดที่อาจไม่มีทางมาถึง ในขณะที่เบี่ยงเบนความพยายามออกจากกิจกรรมที่สำคัญกว่า เช่นการเข้าใจว่าจะมีใครอยากใช้ผลิตภัณฑ์ของเราจริงๆ หรือไม่ Eric Ries เล่าเรื่องราวของการใช้เวลาหกเดือนสร้างผลิตภัณฑ์ที่ไม่มีใครดาวน์โหลดเลย เขาสะท้อนความคิดว่าเขาสามารถแค่ทำลิงก์บนหน้าเว็บที่ 404 เมื่อคนคลิกเพื่อดูว่ามีความต้องการหรือไม่ ใช้เวลาหกเดือนที่ชายหาดแทน และก็ยังได้เรียนรู้เท่ากัน!

ความจำเป็นในการเปลี่ยนระบบของเราเพื่อรับมือกับ scale ไม่ใช่สัญญาณของความล้มเหลว มันคือสัญญาณของความสำเร็จ