Lean Stack: ทำไมเราถึงเลือกเครื่องมือที่ “น่าเบื่อ” และตรงจุด แทนที่จะเป็นเฟรมเวิร์กตัวใหญ่

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

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

นี่ไม่ใช่การ "ทำให้น้อยเข้าไว้" เพื่อความเท่ แต่เป็นจุดยืนที่เราได้มาจากการอยู่กับทางเลือกตรงข้ามมาแล้วจริง ๆ

"น่าเบื่อ" ในที่นี้หมายถึงอะไร

เมื่อเราพูดว่าน่าเบื่อ เราไม่ได้หมายถึงเก่าหรือล้าสมัย เราหมายถึง คาดเดาได้ เครื่องมือที่น่าเบื่อจะทำงานตามชื่อของมัน พังในแบบที่เราเข้าใจเหตุผลได้ และไม่สร้างเซอร์ไพรส์ให้เราตอนตีสอง PostgreSQL น่าเบื่อ ระบบคิวข้อความที่อธิบายจบได้ในกระดาษแผ่นเดียวก็น่าเบื่อ บริการ FastAPI ขนาด 300 บรรทัดที่ทำหน้าที่เดียวก็น่าเบื่อ

เครื่องมือที่น่าเบื่อมีลักษณะร่วมกันอยู่ไม่กี่อย่าง รูปแบบการพังของมันถูกบันทึกไว้อย่างละเอียด เพราะมีทีมงานนับพันเจอมาก่อนหน้าคุณแล้ว ชั้นของการห่อหุ้ม (abstraction) ตื้นพอที่จะเปิดอ่านโค้ดต้นฉบับได้เมื่อจำเป็น และที่สำคัญ ความรู้ที่คุณสั่งสมจากการดูแลมันสามารถนำไปใช้ต่อได้ — ดัชนีของ Postgres ทำงานเหมือนเดิมไม่ว่าจะอยู่เบื้องหลังระบบ ERP หรือระบบค้นหาแบบเวกเตอร์

เครื่องมือที่ "น่าตื่นเต้น" กลับตรงกันข้ามทั้งสามข้อ รูปแบบการพังของมันแปลกใหม่ (ยินดีด้วย คุณคือคนแรกที่ได้แจ้งปัญหา) ชั้นการห่อหุ้มลึกจนการไล่หาบั๊กกลายเป็นการแกะเปลือกทีละชั้นที่คุณไม่ได้เขียนเอง และความเชี่ยวชาญที่ได้มานั้นโอนถ่ายไปใช้ที่อื่นไม่ได้ — มันหายไปในวันที่คุณเลิกใช้เครื่องมือนั้น

เฟรมเวิร์กแก้ปัญหา "โดยเฉลี่ย" แต่ปัญหาของคุณไม่ใช่ปัญหาโดยเฉลี่ย

เฟรมเวิร์กตัวใหญ่คือการเดิมพันว่าปัญหาของคุณหน้าตาเหมือนปัญหาที่ผู้สร้างมันจินตนาการไว้ เมื่อมันเหมือนจริง เฟรมเวิร์กก็เหมือนเวทมนตร์ — คุณได้ระบบล็อกอิน หน้าแอดมิน ORM ระบบ migration และอีกหลายสิบอย่าง เพียงแลกกับการตั้งค่าในไฟล์ config

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

เราเคยเห็นหลายทีมเสียเวลาไปกับการต่อสู้กับความเห็นของเฟรมเวิร์กเรื่องการจัดการ background job หรือสมมติฐานของมันเกี่ยวกับวงจรชีวิตของ request มากกว่าเวลาที่ใช้เขียนสิ่งที่น่าเบื่อ ๆ นั้นขึ้นมาเองเสียอีก เฟรมเวิร์กไม่ได้ช่วยประหยัดงาน มันแค่เลื่อนงานออกไป แล้วคิดดอกเบี้ย

นี่คือหัวใจของจุดยืนเรา เครื่องมือที่สร้างมาเพื่อจุดประสงค์เฉพาะตั้งสมมติฐานเกี่ยวกับปัญหาของคุณน้อยกว่า ซึ่งแปลว่าโอกาสที่สมมติฐานจะผิดก็น้อยกว่าด้วย

เราขีดเส้นแบ่งตรงไหนจริง ๆ

เวอร์ชันที่ซื่อสัตย์ของแนวคิดนี้ต้องยอมรับด้วยว่าเมื่อไหร่ที่เครื่องมือตัวใหญ่คือคำตอบที่ถูกต้อง — เพราะบางครั้งมันก็ใช่จริง ๆ นี่คือวิธีที่เราตัดสินใจ

FastAPI แทน Django — บ่อยครั้ง แต่ไม่ใช่เสมอไป งานส่วนใหญ่ของเราคือบริการขนาดเล็กที่กระชับ ทั้ง AI middleware ชั้นเชื่อมต่อระบบ และ API ภายใน สำหรับงานเหล่านี้ พื้นที่อันเล็กกะทัดรัดของ FastAPI คือคำตอบที่เหมาะที่สุด ตัว soc-integrator middleware ของเรา — ชิ้นส่วนที่เชื่อม Wazuh เข้ากับ DFIR-IRIS ไปยังแพลตฟอร์ม SOAR และระบบแจ้งเตือน — เป็นบริการ FastAPI ที่โฟกัสชัดเจน ก็เพราะมันทำหน้าที่เดียวและต้องเข้าใจได้ง่ายภายใต้แรงกดดันตอนเกิดเหตุ แต่เราก็ยินดีหยิบ Django มาใช้เมื่อโปรเจกต์ต้องการสิ่งที่ Django ทำได้ดีจริง ๆ เช่น หน้าแอดมินที่พร้อมใช้ ระบบ migration ของ ORM ที่สมบูรณ์ หรือแอปที่เน้นเนื้อหา มีผู้ใช้และระบบ session จริง ความผิดพลาดไม่ใช่การใช้ Django แต่คือการใช้มันโดยอัตโนมัติ แล้วไม่เคยแตะครึ่งหนึ่งของมันเลย

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

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

เครื่องมือความปลอดภัยโอเพนซอร์ส แทน SIEM เชิงพาณิชย์ การสร้าง SOC stack บน Wazuh และ OpenSearch แทนที่จะเป็น SIEM เชิงพาณิชย์ราคาหลักล้าน ไม่ใช่การประหยัดงบ แต่เป็นหลักการเดียวกัน นั่นคือเครื่องมือที่เราตรวจสอบได้ ทำเวอร์ชันได้ และปรับให้เข้ากับความต้องการด้านการตรวจจับจริงของลูกค้า โดยไม่มีมิเตอร์คิดค่าลิขสิทธิ์ต่อกิกะไบต์มาคอยกำหนดการตัดสินใจเชิงสถาปัตยกรรมแทนเรา

สังเกตรูปแบบนี้ให้ดี คำถามไม่ใช่ "เครื่องมือไหนเก่งที่สุด" แต่เป็น "เครื่องมือที่เล็กที่สุดที่ความสามารถพอดีกับปัญหานี้ และเราเป็นเจ้าของได้เต็มที่ คือตัวไหน"

ต้นทุนของพื้นที่ผิวที่ทบต้นไปเรื่อย ๆ

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

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

ยังมีมิติเรื่องการจ้างงานอีกด้วย สแต็กที่กระชับและประกอบด้วยเครื่องมือที่คนรู้จักกันทั่วไป หมายความว่าวิศวกรคนถัดไป — ของเราหรือของลูกค้า — จะทำงานได้ภายในไม่กี่วัน ไม่ใช่หลายเดือน เฟรมเวิร์กที่ลึกลับสร้างการพึ่งพาที่ลึกลับกับคนเฉพาะกลุ่มที่เข้าใจมัน ส่วนเครื่องมือที่น่าเบื่อช่วยให้ "bus factor" ของทีมแข็งแรง

เมื่อไหร่ที่เราไม่ทำแบบนี้

แนวคิดนี้ก็มีจุดอ่อนของมัน และเราคงไม่ซื่อสัตย์ถ้าจะแกล้งทำเป็นไม่มี

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

ดังนั้นกฎจึงไม่ใช่ "เครื่องมือเล็กเสมอ" แต่คือ "จับคู่เครื่องมือให้ตรงกับปัญหา และซื่อสัตย์ว่าปัญหาไหนเป็นมาตรฐานจริง ๆ" ระบบล็อกอินเป็นปัญหามาตรฐาน จงใช้ของที่พิสูจน์แล้ว ส่วนการเชื่อมต่อเฉพาะทางระหว่างเครื่องจักรรุ่นเก่าของลูกค้ากับระบบ ERP สมัยใหม่นั้นไม่ใช่ปัญหามาตรฐาน ไม่มีเฟรมเวิร์กไหนยื่นคำตอบนั้นให้คุณได้ และการแกล้งคิดว่ามันมีก็แค่เพิ่มชั้นกั้นระหว่างคุณกับงานเท่านั้น

วินัยอยู่ที่การแยกแยะสองสิ่งนี้ให้ออก และอยู่ที่ความเต็มใจที่จะลบเครื่องมือทิ้ง เมื่อสมมติฐานที่เคยทำให้มันมีเหตุผลนั้นไม่จริงอีกต่อไป

บทสรุป

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

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

นั่นคือการเดิมพันที่เราเลือกทำซ้ำแล้วซ้ำเล่า และจนถึงตอนนี้ ปีที่สามก็ยังพิสูจน์ว่าเราคิดถูก