- แม้จะบอกว่าการ เชื่อมต่อ SaaS ช่วยให้นักพัฒนามุ่งโฟกัสกับตัวผลิตภัณฑ์ได้ แต่ในความเป็นจริงกลับมี ต้นทุนแฝง 5 อย่าง (ภาษี) อยู่เสมอ
- ในแต่ละขั้นตอนก่อนนำมาใช้ ได้แก่ การค้นหา, การสมัคร, การผสานรวม, การพัฒนาแบบโลคัล, การใช้งานจริง จะมีทั้งเวลา ความซับซ้อน และภาระทางจิตใจเกิดขึ้นอย่างต่อเนื่อง
- หากเลือกใช้ แพลตฟอร์มแบบรวมศูนย์ (Cloudflare, Supabase ฯลฯ) แทน SaaS แยกส่วน ก็จะลดต้นทุนและความซับซ้อนที่เกิดซ้ำเหล่านี้ได้มาก
- เนื่องจาก vendor lock-in เป็นความจริงที่หลีกเลี่ยงไม่ได้ ทางเลือกที่ดีที่สุดจึงไม่ใช่การผสมหลายบริการ แต่คือการรักษา โฟลว์การพัฒนา (Flow) ไว้บน แพลตฟอร์มแบบรวมศูนย์เพียงแห่งเดียว
- สุดท้ายแล้ว สิ่งที่สำคัญที่สุดไม่ใช่ เฟรมเวิร์กหรือตัวบริการเอง แต่คือซอฟต์แวร์ที่ฉันต้องการสร้าง
SaaS เป็นเพียง vendor lock-in ที่มีการรีแบรนด์ให้ดีขึ้นเท่านั้น
- นักพัฒนามักได้ยินคำว่า “จงโฟกัสแค่การพัฒนาผลิตภัณฑ์” แต่ในความเป็นจริง เมื่อเริ่มใช้ ผู้ให้บริการ SaaS สำหรับสิ่งอย่าง auth, queue, file storage, image optimization กลับมีภาระหลายอย่างตามมา
- ไม่ได้มีแค่ต้นทุนทางการเงินเท่านั้น แต่ยังมีการสูญเสียเวลา ความฝืด และความเหนื่อยล้าทางจิตใจด้วย
1. ภาษีการค้นหา (Discovery Tax)
- ก่อนนำบริการ SaaS มาใช้ จำเป็นต้องผ่านกระบวนการทำความเข้าใจว่าแท้จริงแล้วมัน ขายฟังก์ชันและคุณค่าอะไร
- ต้องประเมินรายละเอียดต่าง ๆ เช่น ขอบเขตการแก้ปัญหา, ความเข้ากันได้กับสแตกเดิม, ราคาที่สมเหตุสมผลเมื่อเทียบกับขนาดงาน, ความชัดเจนของเอกสาร, วิธีการติดตั้งใช้งานที่มีลักษณะเฉพาะ เป็นต้น
- กระบวนการสำรวจเช่นนี้มักไม่สามารถส่งต่อหรือทำซ้ำจากประสบการณ์ก่อนหน้าได้ง่าย และหลายส่วนก็เป็นการตัดสินใจเชิงอัตวิสัย
- ยังมีภาระที่ต้องตัดสินด้วยตัวเองว่า ข้อความทางการตลาด จะตรงกับเราไหม และบริการนั้นจะช่วยได้จริงหรือไม่
2. ภาษีการสมัคร (Sign-Up Tax)
- หลังจากเลือกบริการแล้ว ต้องให้ อีเมลและข้อมูลบัตร
- ต้องตรวจสอบว่าสามารถคิดค่าบริการตามการใช้งานจริงได้หรือไม่ หรือรองรับแค่การผูกติดแบบสมัครสมาชิกเท่านั้น
- โครงสร้างราคาที่ไม่โปร่งใสก็เป็นปัญหา เช่น การที่สมาชิกทีมต้องเสียค่าใช้จ่ายเพิ่มเพื่อเข้าถึงแดชบอร์ด
- ต้องเช็กว่าสามารถทดสอบได้โดยไม่ต้องมีช่วงทดลองใช้ฟรีหรือไม่ และมีการบังคับให้จ่ายเงินตั้งแต่แรกหรือเปล่า
- ก่อนจะเขียนโค้ดแม้แต่บรรทัดเดียว ก็ได้เกิดความสัมพันธ์เชิงสัญญากับผู้ให้บริการแล้ว
3. ภาษีการผสานรวม (Integration Tax)
- ในกระบวนการนำมาใช้จริง จำเป็นต้อง อ่านเอกสาร, ติดตั้งไลบรารี, เชื่อมเข้ากับเฟรมเวิร์ก, และแก้ปัญหาเพิ่มเติมนอกเหนือจากเอกสาร
- มักต้องเผชิญกับการชนกันของเครื่องมือหรือปัญหาที่ไม่คาดคิด
- เมื่อ SaaS รองรับเพียง ตัวหารร่วมต่ำสุด ของกรณีใช้งาน งานก็จะเพิ่มขึ้นอีกสำหรับสแตกสมัยใหม่หรือสภาพแวดล้อมเฉพาะทาง
4. ภาษีการพัฒนาแบบโลคัล (Local Development Tax)
- ไม่แน่ชัดว่าบริการ SaaS จะ รองรับสภาพแวดล้อมโลคัล หรือไม่
- จำเป็นต้องมี local emulator หรือความสามารถในการทำ stub เพื่อการทดสอบ
- บางครั้งการตรวจสอบฟีเจอร์บางอย่างยังต้องใช้ cloud tunneling ทำให้การตั้งค่าสภาพแวดล้อมซับซ้อนขึ้น
- จึงหลีกเลี่ยงไม่ได้ที่จะต้องแยกการตั้งค่าระหว่าง production, staging, local
5. ภาษีโปรดักชัน (Production Tax)
- หลังผสานบริการแล้ว ก็จะเกิดภาระใหม่ใน สภาพแวดล้อม production
- ต้องมีการจัดการเพิ่มเติม เช่น การใช้งานใน staging และ PR preview environment, การจัดการ API key, monitoring, logging, การแจ้งเตือน เป็นต้น
- ต้องเตรียมรับมือกับ error หรือความไม่สอดคล้องที่ไม่เกิดในสภาพแวดล้อมพัฒนา แต่เกิดขึ้นเฉพาะตอนใช้งานจริง
- ความรับผิดชอบในการรักษาเสถียรภาพของบริการสุดท้ายก็ตกมาที่นักพัฒนาอยู่ดี
บทสรุป
- สโลแกนของ SaaS ยุคใหม่ คือ “อย่าสร้างวงล้อขึ้นมาใหม่” แต่ทุกครั้งที่เพิ่มบริการเข้าไปก็ย่อมมีความฝืดตามมา
- การนำบริการมาใช้ไม่ใช่แค่การผสานรวมธรรมดา แต่คือ สัญญา และมาพร้อมกับการเพิ่ม dependency รวมถึงการเปลี่ยนแปลงสถาปัตยกรรม vendor lock-in เป็นสิ่งที่หลีกเลี่ยงไม่ได้ และเมื่อจะเปลี่ยนบริการก็ต้องแบกรับภาระการเขียนโค้ดใหม่จำนวนมาก
- ดังนั้น แทนที่จะต้องตัดสินใจลักษณะนี้ซ้ำ ๆ การเลือก แพลตฟอร์มแบบ all-in-one ตั้งแต่แรกจึงมีประสิทธิภาพกว่า
- สิ่งสำคัญคือซอฟต์แวร์ที่นักพัฒนาต้องการสร้างจริง ๆ
- แพลตฟอร์มแบบรวมศูนย์อย่าง Cloudflare, Supabase มอบทั้งฐานข้อมูล, queue, image, storage ภายใต้สภาพแวดล้อมเดียวกัน จึงช่วยลดภาระเรื่องภาษีที่กล่าวมาข้างต้นได้อย่างมาก
- ไม่จำเป็นต้องสลับบริบท (context switching) ระหว่างผู้ให้บริการหลายราย
- ปัญหาจากการจัดการ API key เกิดน้อยลง
- ลดความจำเป็นในการจัดการความเข้ากันได้และการแยกสาขาตามสภาพแวดล้อมให้เหลือน้อยที่สุด
- มอบประสบการณ์การผสานรวมที่สอดคล้องกันทั้งในสภาพแวดล้อมพัฒนาและ production
- แพลตฟอร์มลักษณะนี้ให้ความรู้สึกราวกับว่าทุกอย่างทำงานอยู่บนเครื่องเดียวกัน ลดระยะห่างระหว่างโค้ดกับบริการลงให้มากที่สุด และช่วยดึง ภาวะลื่นไหลในการพัฒนา ("Flow") กลับคืนมา ซึ่งเป็นสิ่งที่ SaaS ใดก็ให้ไม่ได้
> สิ่งสำคัญไม่ใช่การเลือกเฟรมเวิร์กหรือบริการ แต่คือการรักษาซอฟต์แวร์ที่ฉันต้องการสร้างและโฟลว์ (Flow) ของมันไว้
2 ความคิดเห็น
มีการยก Supabase เป็นตัวอย่างที่ดีอยู่ แต่ถ้าอย่างนั้น SaaS แบบไหนบ้างที่ควรหลีกเลี่ยง?
ความคิดเห็นจาก Hacker News
นี่คือมุมมองที่เห็นว่าเป็นการขยายแนวคิด “rent seeking(การแสวงหาค่าเช่า)” ของ Adam Smith ในยุคปัจจุบันแบบมหาศาล
มองว่ากิจกรรมทางเศรษฐกิจแบบนี้เป็นโทษต่อสังคม จึงควรหลีกเลี่ยงและถึงขั้นควรทำให้ผิดกฎหมาย
ขณะเดียวกัน สุดโต่งอีกด้านของซอฟต์แวร์ฟรีก็มีปัญหาเชิงเศรษฐกิจเช่นกัน เพราะความพยายามของผู้สร้างซอฟต์แวร์ไม่ได้สัดส่วนกับคุณค่าที่ผู้ใช้ได้รับ
จึงเสนอว่าการซื้อซอฟต์แวร์กับการทำสัญญาบริการควรแยกจากกัน และแต่ละส่วนต้องให้คุณค่าที่ต่างกันจริง
ปัญหาของ SaaS คือการเอาสิ่งเหล่านี้มามัดรวมกัน จนในทางปฏิบัติส่วนของการแพ็กเกจกลับบิดเบี้ยวเกินจริงยิ่งกว่าตัวบริการเอง
ถ้าคิดจริงจังขนาดนั้น ก็ต้องไปสร้าง SaaS เองแล้วตั้งบริษัทที่ทำดีพลอยและดูแลแบบ on-premises ให้ลูกค้า โดยคิดราคาใกล้เคียงกับ SaaS ปัจจุบัน
ถ้าสามารถให้ทั้งการควบคุมข้อมูล ป้องกัน vendor lock-in และยังคงคุณภาพ การรับประกัน และราคาได้เทียบเท่า SaaS ก็อาจครองตลาดได้
ผมคิดเรื่องนี้อยู่เสมอว่า ถ้าแจกแค่ไบนารีแล้วให้ผู้ใช้ไปรันบน AWS, GCP หรือ cloudflare workers เองจะได้ไหม
สำหรับผม saas น่าสนใจในฐานะนักพัฒนา แต่ไม่ชอบในฐานะผู้บริโภค เลยกลายเป็นภาวะกลืนไม่เข้าคายไม่ออกทางจริยธรรม
ถ้าผมขายซอฟต์แวร์ แล้วผู้ใช้เอาไปแจกต่อโดยไม่ได้รับอนุญาตจะทำอย่างไร? คงควบคุมการแจกจ่ายไม่ได้แบบ saas
ผมสนับสนุน foss(โอเพนซอร์ส) แต่แบบที่คุณว่าก็มีปัญหาเชิงเศรษฐกิจเหมือนกัน
ก็กำลังคิดถึงแนวทางอย่างออกไลเซนส์ผ่าน GitHub Sponsors หรือบางโปรเจกต์ก็ใช้โมเดลที่ยืนยันตัวตนแบบ SSPL แล้วเปลี่ยนเป็น BSD/MIT เมื่อซื้อไลเซนส์แล้ว (คล้าย redis สมัยก่อน)
แต่ก็ยังสงสัยว่าถ้าใช้โมเดลนี้จริงคนจะยอมซื้อไหม และก็คิดจะรองรับทั้งสองแนวทางอยู่ แต่ยังไม่มีคำตอบชัดเจน เลยอยากขอคำแนะนำ
โปรเจกต์ที่ผมทำมีทั้งเครื่องมือให้ใครก็สร้างคริปโตเคอร์เรนซีได้ฟรี ฟีเจอร์ดึงบล็อกจาก YouTube และสตอเรจไม่จำกัดที่ใช้ YouTube Community กับวิดีโอแทน Google Photos รวมถึงกำลังคิดเรื่องเสริมความเป็นส่วนตัวอยู่ด้วย ถ้ามีไอเดียทำเงินก็อยากฟัง
SaaS ส่วนใหญ่ในมุมผู้ให้บริการมีต้นทุนต่อเนื่องทั้งโฮสติ้ง การซัพพอร์ต และ R&D
เลยยากจะเห็นด้วยกับตรรกะที่บอกว่าโครงสร้างแบบนี้คือ “การแสวงหาค่าเช่า”
ไม่ใช่ว่า SaaS ทั้งหมดจะเป็นการแสวงหาค่าเช่า และตัว “stickiness(ความติดหนึบ, การล็อกอิน)” ของซอฟต์แวร์เองต่างหากที่โดยธรรมชาติคล้าย rent-seeking
ผู้ให้บริการ SaaS ส่วนใหญ่พยายามสร้าง stickiness แต่ก็ไม่ใช่คุณสมบัติเฉพาะของ SaaS
ผมก็แค่ขายผลิตภัณฑ์ SaaS ของตัวเองให้ลูกค้าที่พร้อมจ่ายในราคาสมเหตุสมผลในตลาด
ปกติ vendor lock-in จะรู้สึกชัดเวลาถามกันในบริษัทว่า “ทำไมไม่ใช้เครื่องมือ NEWTHING ล่ะ?” แล้วคำตอบคือทำไม่ได้ เพราะเซ็นสัญญาระยะยาว 5 ปีกับ Oracle, MS, IBM หรือ Salesforce ไปแล้ว
แล้วพอผ่านไปสัก 10 ปี โครงสร้างแบบนี้ก็ทำให้ถูกมัดติดกับผู้ขายนั้นจริง ๆ จนเปลี่ยนไม่ได้อีก
ถ้าธุรกิจอยู่รอดได้ถึง 10 ปี ปัญหานี้ก็อาจถือเป็นพรหรืออย่างน้อยก็เป็นปัญหาที่น่าเบื่อมากกว่าจะร้ายแรง แต่สำหรับช่วงเริ่มต้น ผมอยากแนะนำว่าอย่าเสียเวลากับการเลือกเครื่องมือหลายตัว ให้เลือกแพลตฟอร์มหนึ่งอย่างรวดเร็วแล้วโฟกัสไปเลย
แม้ในกรณีแบบนี้ก็ยังเห็นว่าควรทำ abstraction ของบริการต่าง ๆ ไว้หลังอินเทอร์เฟซมาตรฐาน
ถ้าทำ abstraction ไว้แล้ว ภายหลังจะย้ายไปบริการอื่นก็แค่ทำ implementation ทางเลือกเพิ่ม
นี่เป็นวิธีที่มองไกล แต่ก็ชี้ว่าหลายบริษัททุกวันนี้ยังเตรียมตัวเรื่องนี้ไม่พอ
ผมคิดว่าการลด dependency ให้ต่ำที่สุดเป็นหนึ่งในปัจจัยสำคัญที่สุดในการเพิ่มความยั่งยืนของทั้งผลิตภัณฑ์และธุรกิจ
ที่ทำงานเก่าของผม ผมรับผิดชอบงานรวมประสบการณ์ลายเซ็นอิเล็กทรอนิกส์แบบ DocuSign เข้ากับผลิตภัณฑ์ของเรา
เราคุยกับผู้ขายหลักอย่าง DocuSign, Adobe และรายอื่น ๆ แต่พบว่า API มีข้อจำกัดเยอะ ไม่ตอบโจทย์ผลิตภัณฑ์และความต้องการลูกค้าเท่าไร สุดท้ายเลยตัดสินใจทำเองภายใน
ปกติการไปสร้างเครื่องมือแบบ DocuSign เองถือเป็นการตัดสินใจที่ไม่ดี แต่ผลิตภัณฑ์ของเรามีความเชื่อมั่นจากลูกค้าอยู่แล้ว เลยมีแรงต้านการนำไปใช้น้อย
ช่วงแรกการทำเองงานเยอะมาก แต่เวลาอยากปรับเล็ก ๆ ให้เข้ากับลูกค้าจริงก็ทำได้เร็วมาก และถ้าใช้ผู้ขายภายนอก งานนั้นน่าจะกลายเป็นโปรเจกต์ใหญ่ที่ยุ่งยากกว่านี้มาก จึงมองว่าการทำเองเป็นทางเลือกที่ถูกต้อง
ผมเข้าใจว่าผู้เขียนกำลังบอกว่า SaaS คือ vendor lock-in เลยไม่ควรซื้อ
แต่ในบทความกลับแนะนำให้ all-in กับแพลตฟอร์มเฉพาะอย่าง Cloudflare
สุดท้ายไม่ว่าเลือกแบบไหนก็ lock-in ทั้งนั้น แม้แต่โอเพนซอร์สหรือ self-hosting ถ้าจะเปลี่ยนก็ยังต้องเขียนโค้ดใหม่จำนวนมาก
การใช้ฟีเจอร์ที่ผูกกับผู้ขายเฉย ๆ กับ “lock-in จริง ๆ” นั้นต่างกัน โดย lock-in จะเกิดขึ้นเมื่อการเปลี่ยนไปใช้อย่างอื่นมีต้นทุนและเวลามากกว่าการอยู่แบบเดิม
ถ้าทำซอฟต์แวร์ให้ loosely coupled และมี cohesion ดี การเปลี่ยนบางส่วนจะง่าย
เพราะถ้าอินเทอร์เฟซเรียบง่าย การสลับเปลี่ยนก็ง่ายตาม
ดังนั้นการเลือกแบบ “ไหน ๆ ก็ lock-in หมดแล้ว งั้นผูกกับแพลตฟอร์มเดียวให้แน่นไปเลย” อาจสะดวกสำหรับนักพัฒนา แต่เป็นกลยุทธ์ที่ไม่ดีสำหรับผู้บริหาร และควรโฟกัสที่ความยืดหยุ่นและความสามารถในการเปลี่ยนแปลงของบริษัทมากกว่า
ในมุมคนทำธุรกิจ ควรเลือกโซลูชันที่ทำให้บริษัทมีความยืดหยุ่นและปรับเปลี่ยนได้ และการปล่อยให้ตัวเองถูกมัดกับ SaaS โดยไม่มีทางเลือกสำรองนั้นเป็นเรื่องไม่ฉลาด
ช่วงเริ่มต้นหรือยังไม่มีรายได้ การใช้แพลตฟอร์มได้เปรียบกว่า SaaS แต่เมื่อโตจนถึงช่วงขยาย ก็สมควรเริ่มคิดถึงการเปลี่ยนแปลงทางเทคโนโลยีในระยะยาว
ผมใช้ cloudflare workers บ่อย และก็เขียนโค้ดให้ย้ายไปรันที่อื่นได้ด้วย
รัน local ได้ด้วย
wrangler devและในทางปฏิบัติก็ทำงานบน pure node/bun/deno ได้โดยแทบไม่ต้องแก้อะไรมากOP(ผู้เขียนต้นโพสต์) ไม่ได้คัดค้าน SaaS โดยตัวมันเอง (สุดท้ายก็ยังแนะนำโซลูชันแบบ as a service อย่าง Cloudflare หรือ Supabase) แต่ประเด็นหลักคือกำลังชี้ถึงต้นทุนการดำเนินงานและภาระการจัดการความสัมพันธ์ที่เกิดจากการต้องทำสัญญาและดูแลผู้ให้บริการจำนวนมาก
ยิ่งมีผู้ขายน้อย ยิ่งมี dependency น้อย การดำเนินงานก็ยิ่งง่าย
แนวคิดว่าทุกอย่างควรทำด้วย standard library ล้วน ๆ นั้นฟังดูอุดมคติเกินไป และในโลกจริงทำได้ยากมาก
แก่นของข้อเสนอคือ ตอนเริ่มต้นอย่าผสมหลายบริการเข้าด้วยกัน ให้ลองใช้แพลตฟอร์มเดียวก่อน
เหตุผลที่ผมชอบ cloudflare ก็เพราะมันทำ binding ให้เป็นมาตรฐานคล้าย
fetchซึ่งทำให้fetchให้ความรู้สึกเหมือน Unix pipe ของโลกเว็บมีมุมมองว่ามันช่างประชดดีที่บอกว่าจะหลีกเลี่ยง vendor lock-in แต่กลับ all-in ทุกอย่างลงแพลตฟอร์มเดียว จนผูกตัวเองหนักกว่าเดิมกับบริษัทเดียว
เพราะ SaaS เองก็มีต้นทุนการกระจายตัวแบบ “ภาษี” เช่นกัน
จริง ๆ แล้วการถกเถียงนี้ดูใกล้เคียงกับการสนับสนุนโอเพนซอร์สมากกว่า
ถ้าใช้โอเพนซอร์สกับ self-host ก็จะลด “ภาษี” ส่วนใหญ่ที่บทความพูดถึงได้ เช่น ต้นทุนด้านการค้นหา การสมัคร การรวมระบบ และงานพัฒนา local
ส่วน production tax(ภาระฝั่งปฏิบัติการ) ของโอเพนซอร์ส น่าจะแก้ได้ด้วยการมี ecosystem ที่คึกคัก หรือระบบปลั๊กอินและโมดูล
(เปรียบกับความต่างระหว่างศาสนากับลัทธิ) ถ้าสามารถดึงข้อมูลออกมาในรูปแบบมาตรฐานแล้วจากไปได้ ก็ไม่ถือว่าเป็น vendor lock-in
ลูกค้าจะรู้สึกว่าตัวเองไม่ได้ถูกเอาเปรียบมากนักเมื่อได้ข้อมูลของตัวเองกลับมา แต่ปัญหาคือ SaaS จำนวนมากกลับทำสิ่งนี้ไม่ได้
ตอนนี้ผมมักเผยแพร่แบบ MIT เป็นหลัก และเก็บส่วนสำคัญไว้เป็นปิดซอร์ส
ข้อจำกัดของ SaaS คือทำให้ลูกค้าไม่ได้รับประโยชน์จาก “ต้นทุนส่วนเพิ่มที่เกือบเป็นศูนย์” ของซอฟต์แวร์อย่างเต็มที่
ผู้ให้บริการ SaaS อาจสะท้อนประโยชน์นั้นกลับมาบ้างผ่านราคาที่ถูกลง แต่เมื่อผู้ใช้มากพอและราคาต่อหน่วยสูงขึ้น สุดท้ายฝ่ายที่ใช้ SaaS มักจะเสียเปรียบ
แต่ในระยะเริ่มต้นของสตาร์ตอัป การสร้างเองถือเป็นทางเลือกที่บ้าบิ่น และในช่วงที่เป้าหมายคือ “อยู่รอด” กับ “ลดต้นทุนเริ่มต้น” SaaS เป็นกลยุทธ์ที่ฉลาดมาก
พอธุรกิจเติบโตและ SaaS ฝังลึกในงานประจำวันแล้ว ปัญหาเรื่อง lock-in, การย้ายระบบ และต้นทุนการเปลี่ยนจึงค่อยเกิดขึ้น
เพราะฉะนั้นปัญหาของ SaaS เองก็อาจมองได้ว่าเป็นผลข้างเคียงของความสำเร็จ
นั่นจึงเป็นเหตุผลว่าทำไมโมเดล SaaS แบบนี้ถึงมีอยู่มหาศาล
มันเป็นโมเดลธุรกิจที่น่าดึงดูดมาก เพราะมีรายได้ประจำไหลเข้าซ้ำ ๆ คล้ายเงินบำนาญ และยังมีอำนาจในการกำหนดราคาอีกด้วย