สนับสนุนสถาปัตยกรรมที่เรียบง่าย (2022)

 (danluu.com)
46 คะแนน โดย xguru 2024-03-11 | 9 ความคิดเห็น | แชร์ทาง WhatsApp
  • Wave เป็นบริษัทมูลค่า $1.7B (2.3 ล้านล้านวอน) ที่มีวิศวกร 70 คน (ให้บริการโมบายแบงก์กิ้งสำหรับแอฟริกา)
  • ใช้สถาปัตยกรรมแอป CRUD มาตรฐานแบบ Python monolith บนพื้นฐานของ Postgres
  • การเริ่มจากสถาปัตยกรรมที่เรียบง่ายและแก้ปัญหาโดยลดความซับซ้อนให้น้อยที่สุด ทำให้วิศวกรสามารถโฟกัสกับการสร้างคุณค่าให้ผู้ใช้ได้
  • Stackoverflow ก็เติบโตได้อย่างประสบความสำเร็จจากการขยาย monolith จนถูกซื้อกิจการที่มูลค่า 1.8 พันล้านดอลลาร์

แม้สถาปัตยกรรมที่เรียบง่ายจะมีประสิทธิภาพ แต่สื่อส่วนใหญ่มักชอบสถาปัตยกรรมที่ซับซ้อน

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

วิธีรักษาความเรียบง่าย

  • Wave ใช้ Python แบบ synchronous ซึ่งหมายความว่าโปรเซสของเซิร์ฟเวอร์จะถูกบล็อกระหว่างรอ I/O
  • เคยลองใช้เฟรมเวิร์ก asynchronous อย่าง Eventlet แต่มีบั๊กมากเกินไป จึงตัดสินใจว่าต้นทุนนั้นไม่คุ้มกับความเจ็บปวดในการปฏิบัติการ
  • แทนที่จะเพิ่มความซับซ้อน งานที่ใช้เวลาทำงานนานจะถูกแยกไปประมวลผลผ่านคิว
  • เพื่อให้สอดคล้องกับข้อกำหนดด้าน data residency บางประเทศจำเป็นต้องใช้งานดาต้าเซ็นเตอร์แบบ on-premises
    • เซเนกัล/โกตดิวัวร์ใช้คลาวด์ แต่ยูกันดาและประเทศอื่น ๆ ต้องใช้ on-premises เพราะข้อกำหนด
    • ในกรณีเช่นนี้ สถาปัตยกรรมที่เรียบง่ายจะง่ายกว่าสถาปัตยกรรมที่ซับซ้อนมาก

สร้างเองแทนการซื้อ

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

ตัวเลือกที่กำลังทบทวน

  • กำลังทบทวนการเลือกใช้เทคโนโลยีอย่าง RabbitMQ, Celery, SQLAlchemy และ Python เพราะสิ่งเหล่านี้เพิ่มความซับซ้อนหรือภาระในการบำรุงรักษา
  • หากต้องเริ่ม codebase ใหม่ ก็จะพิจารณาทางเลือกเหล่านี้อย่างรอบคอบ

ตัวเลือกที่พอใจ

  • พอใจกับการเลือกใช้ GraphQL, โปรโตคอลทรานสปอร์ตแบบกำหนดเอง และ Kubernetes
  • GraphQL มีข้อดีอย่างการทำเอกสารได้ด้วยตัวเอง, การสร้างโค้ด, และตัวสำรวจแบบอินเทอร์แอ็กทีฟ GraphiQL
  • มองว่าการใช้ GraphQL มีข้อดีมากกว่าข้อเสีย
    • ข้อดี
      • มีเอกสารในตัวเกี่ยวกับชนิดข้อมูลที่ส่งกลับอย่างแม่นยำ
      • ไคลเอนต์ปลอดภัยขึ้นจากการสร้างโค้ดตามชนิดข้อมูลที่ส่งกลับอย่างแม่นยำ
      • เพิ่มประสิทธิภาพการทำงานด้วยตัวสำรวจแบบโต้ตอบ GraphiQL
      • แอปหลายแบบ (แอปผู้ใช้, แอปซัพพอร์ต, แอปตัวแทน Wave ฯลฯ) สามารถใช้ API เดียวร่วมกันได้เป็นส่วนใหญ่ จึงลดความซับซ้อนลง
      • ด้วยภาษา query ที่กำหนดองค์ประกอบได้ ไคลเอนต์สามารถดึงข้อมูลที่ต้องการได้อย่างแม่นยำใน packet round-trip เดียว โดยไม่ต้องสร้าง endpoint เฉพาะทางจำนวนมาก
      • ตัดปัญหา bikeshedding เกี่ยวกับสิ่งที่ควรถูกนับว่าเป็น RESTful API
    • ข้อเสีย
      • ตอนที่นำ GraphQL มาใช้ ไลบรารี GraphQL ยังไม่ดีมากนัก
      • การเข้ารหัส GQL แบบพื้นฐานมีความซ้ำซ้อน และเพราะลูกค้าจำนวนมากใช้แบนด์วิดท์ต่ำ จึงให้ความสำคัญกับข้อจำกัดด้านขนาดอย่างมาก
  • Kubernetes ถูกใช้เพื่อรองรับข้อกำหนดด้านการดำเนินงานดาต้าเซ็นเตอร์แยกตามประเทศ

บทสรุป

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

บทความที่เกี่ยวข้อง

9 ความคิดเห็น

 
secret3056 2024-03-18

ดูเหมือนว่า “สร้างแทนซื้อ” ควรจะเป็น “ซื้อแทนสร้าง” มากกว่านะครับ

Another area is with software we’ve had to build (instead of buy).
 
xguru 2024-03-18

อ๊ะ ตอนแรกกะจะเน้นย้ำ แต่ดันทำให้ชื่อเรื่องออกมาแปลกไปหน่อย เลยแก้ไขแล้วครับ ขอบคุณครับ
 
savvykang 2024-03-12

เป็นเพราะกระแสเปลี่ยนไปตามวัฏจักรเศรษฐกิจหรือเปล่า? ไม่ว่ากระแสจะเป็นอย่างไร การเริ่มต้นด้วยโมโนลิธย่อมได้เปรียบกว่าในแง่การลดต้นทุนคงที่และการบำรุงรักษา
 
aer0700 2024-03-12

สถาปัตยกรรมที่เข้าใจง่ายก็ย่อมบำรุงรักษาได้ง่ายเช่นกัน
 
mhj5730 2024-03-12

สำหรับผม ไม่ว่าบริการแบบไหนก็ควรเริ่มต้นด้วยโมโนลิทิกจะดีกว่า ถ้าตั้งธงเป็น MSA ตั้งแต่แรกก็สิ้นเปลืองเงินเปล่าๆ
 
dhlee0305 2024-03-11

"เมื่อความซับซ้อนเพิ่มขึ้น ต้นทุน (เงิน คน เวลา...) ก็เพิ่มขึ้นด้วย"
"อย่าพยายามแก้ปัญหาที่แก้ได้ด้วยสถาปัตยกรรมที่เรียบง่าย ด้วยสถาปัตยกรรมที่ซับซ้อน"
 
xguru 2024-03-11

ความคิดเห็นจาก Hacker News

  • คำแนะนำด้านวิศวกรรมเกี่ยวกับไมโครเซอร์วิส

    • ไมโครเซอร์วิสไม่ใช่กลยุทธ์เพื่อเพิ่มประสิทธิภาพ แต่เป็นกลยุทธ์เพื่อลดต้นทุนที่อาจเป็นไปได้และเพื่อการประสานงานทางวิศวกรรม
    • ระหว่างแอปพลิเคชันแบบโมโนลิธิกที่สเกลในแนวนอนได้กับไมโครเซอร์วิส แทบไม่มีความแตกต่างมากนัก ยกเว้นเมื่อคุณต้องการย่อขนาดฟังก์ชันบางอย่างโดยเฉพาะ
    • ในแอปแบบโมโนลิธิก เป็นไปไม่ได้ที่จะย่อขนาดเฉพาะบางส่วนของแอป
    • การลดต้นทุนเริ่มเห็นผลเมื่ออยู่ในสเกลใหญ่ และต้องมีอย่างน้อย 3 replicas
    • สำหรับบริษัทส่วนใหญ่ ประโยชน์ที่แท้จริงอยู่ที่การประสานงานทางวิศวกรรม
    • ในโมโนลิธิกที่มีรีโพเดียว ทีมเดียวสามารถเป็นเจ้าของและดูแลได้ แต่ใน shared monolith จะไม่มีใครเป็นเจ้าของ ทำให้จัดการได้ยาก

  • ประเด็นพูดคุยเกี่ยวกับไมโครเซอร์วิส

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

  • อคติทางความคิดและความเรียบง่าย

    • ผู้คนมักมุ่งไปที่การเพิ่มบางอย่างเข้าไป และมองข้ามวิธีแก้ปัญหาที่เรียบง่าย
    • งานวิจัยแสดงให้เห็นว่า การแก้ปัญหาด้วยการเอาชิ้นส่วนออกแทนที่จะเพิ่มอิฐเข้าไปในโครงสร้างเลโก้ มักเป็นทางออกที่ดีกว่า

  • การทำวิศวกรรมเกินความจำเป็นและการขาดประสบการณ์

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

  • บริษัทที่ให้ความสำคัญกับสมดุลระหว่างงานกับชีวิต

    • กำลังมองหาบริษัทที่อยากโฟกัสกับการปรับปรุงผลิตภัณฑ์ และใช้เวลาที่เหลือกับชีวิตส่วนตัว

  • ประสบการณ์ส่วนตัวเกี่ยวกับ Dan Luu

    • Dan Luu ใจกว้างในการสื่อสารกับแฟนบล็อก และมีความเชี่ยวชาญเรื่องรอยต่อระหว่างซอฟต์แวร์กับฮาร์ดแวร์
    • เขาแบ่งปันมุมมองและความเชี่ยวชาญอย่างไม่หวง และการได้เรียนรู้จากเขาเป็นประสบการณ์ที่น่ายินดีมาก

  • ความสำคัญของสถาปัตยกรรมที่เรียบง่าย

    • ในกรณีส่วนใหญ่ สถาปัตยกรรมที่ต้องการก็คือองค์ประกอบพื้นฐาน เช่น load balancer ที่รองรับ SSL, app server หลายตัว, ฐานข้อมูลที่ทำ sharding, message queue เป็นต้น

  • สถาปัตยกรรมกับโครงสร้างทางสังคมของทีมวิศวกรรม

    • สถาปัตยกรรมควรสะท้อนโครงสร้างทางสังคมของทีมวิศวกรรม และหากไม่คำนึงถึงเรื่องนี้ ก็อาจทำให้เกิดความสับสนและความไร้ประสิทธิภาพ
    • รีโพแบบโมโนลิธิกขนาดใหญ่และสถาปัตยกรรมที่เรียบง่ายอาจจัดการได้ยาก และแม้แต่บริษัทอย่าง Google และ Meta ก็ยังพัฒนาเครื่องมือภายในจำนวนมาก
    • สถาปัตยกรรมสามารถช่วยสนับสนุนหรือขัดขวางการทำงานร่วมกันระหว่างทีมได้ ดังนั้นผู้นำด้านเทคนิคจึงควรคำนึงถึงเรื่องนี้

  • ความชอบต่อสถาปัตยกรรมที่เรียบง่าย

    • สถาปัตยกรรมที่เรียบง่ายและโมโนลิธิกมักเหมาะสมที่สุดในกรณีส่วนใหญ่ แต่ต้องระวังไม่ให้เกิดปัญหาจาก synchronous IO
    • บั๊กด้านความสมบูรณ์ของข้อมูลเป็นปัญหาสำคัญที่ต้องหลีกเลี่ยงในระบบการเงิน.
 
dangyup 2024-03-18

ขอรบกวนลิงก์ของงานบรรยายที่พูดถึง "เคล็ดลับเกี่ยวกับความล้มเหลวของไมโครเซอร์วิสของ David Schmitz" ได้ไหมครับ