- Tích hợp SaaS được cho là giúp nhà phát triển chỉ tập trung vào sản phẩm, nhưng trên thực tế luôn tồn tại 5 loại chi phí ẩn (thuế) lặp đi lặp lại
- Ở từng giai đoạn khám phá, đăng ký, tích hợp, phát triển cục bộ, vận hành, thời gian, độ phức tạp và gánh nặng tinh thần liên tục phát sinh
- Nếu chọn nền tảng tích hợp (Cloudflare, Supabase, v.v.) thay vì SaaS riêng lẻ, có thể giảm mạnh các chi phí lặp lại và độ phức tạp này
- Vendor lock-in là thực tế khó tránh, vì vậy thay vì trộn nhiều dịch vụ, tốt nhất là giữ luồng phát triển (Flow) trong một nền tảng tích hợp duy nhất
- Cuối cùng, điều quan trọng nhất không phải framework hay bản thân dịch vụ, mà là phần mềm tôi muốn xây dựng
SaaS chỉ là vendor lock-in được đổi thương hiệu tốt hơn
- Các nhà phát triển thường nghe câu “hãy chỉ tập trung vào phát triển sản phẩm”, nhưng trên thực tế, khi đưa vào các nhà cung cấp SaaS như auth, queue, lưu trữ tệp, tối ưu hình ảnh, nhiều gánh nặng khác nhau sẽ phát sinh
- Không chỉ có chi phí tiền bạc, mà còn có tiêu tốn thời gian, ma sát và cả mệt mỏi tinh thần.
1. Thuế khám phá (Discovery Tax)
- Trước khi áp dụng một dịch vụ SaaS, cần có quá trình xác định chính xác tính năng và giá trị mà nó đang bán
- Cần đánh giá các yếu tố chi tiết như phạm vi giải quyết vấn đề, khả năng tương thích với stack hiện có, mức giá có hợp lý theo quy mô hay không, tài liệu có rõ ràng không, có cách triển khai đặc thù nào không
- Quá trình điều tra này không dễ được chia sẻ hay lặp lại từ kinh nghiệm trước đó, và phần lớn mang tính quyết định chủ quan
- Có gánh nặng phải tự đánh giá liệu thông điệp marketing có phù hợp với mình hay không, và dịch vụ có thực sự hữu ích hay không
2. Thuế đăng ký (Sign-Up Tax)
- Sau khi chọn dịch vụ, phải cung cấp email và thông tin thẻ
- Cần xem liệu có thể tính phí theo mức sử dụng hay chỉ hỗ trợ lock-in kiểu thuê bao
- Cấu trúc giá thiếu minh bạch là vấn đề, chẳng hạn phát sinh chi phí bổ sung chỉ để thành viên nhóm truy cập dashboard
- Cần kiểm tra xem có thể thử nghiệm mà không cần bản dùng thử miễn phí hay không, và liệu có bị yêu cầu thanh toán ngay từ đầu hay không
- Ngay cả trước khi viết một dòng code, quan hệ hợp đồng với vendor đã được hình thành
3. Thuế tích hợp (Integration Tax)
- Trong quá trình áp dụng thực tế, việc đọc tài liệu, cài thư viện, kết nối framework, xử lý thêm các vấn đề ngoài tài liệu là bắt buộc
- Thường xuyên phải đối mặt với xung đột công cụ hoặc những vấn đề ngoài dự kiến
- Khi SaaS chỉ nhắm đến mẫu số chung tối thiểu, sẽ cần nhiều việc hơn trong các stack hiện đại hoặc môi trường chuyên biệt
4. Thuế phát triển cục bộ (Local Development Tax)
- Không rõ liệu dịch vụ SaaS có hỗ trợ môi trường cục bộ hay không
- Cần có local emulator hoặc khả năng stub cho mục đích kiểm thử
- Để kiểm tra một số tính năng, đôi khi cần cloud tunneling, khiến việc cấu hình môi trường trở nên phức tạp
- Tình huống buộc phải tách cấu hình cho production, staging, local là khó tránh khỏi
5. Thuế production (Production Tax)
- Sau khi tích hợp dịch vụ, các gánh nặng mới lại xuất hiện trong môi trường production
- Cần thêm việc quản lý cho khả năng dùng trong staging và môi trường preview của PR, quản lý API key, monitoring, logging, cảnh báo, v.v.
- Phải chuẩn bị cho lỗi hoặc sai khác không xuất hiện trong môi trường phát triển nhưng chỉ phát sinh ở môi trường vận hành thực tế
- Trách nhiệm duy trì độ ổn định của dịch vụ cuối cùng lại bị chuyển cho nhà phát triển
Kết luận
- Khẩu hiệu của SaaS hiện đại là "đừng phát minh lại bánh xe", nhưng mỗi lần thêm dịch vụ đều kéo theo ma sát
- Việc áp dụng dịch vụ không chỉ là tích hợp đơn giản mà là một hợp đồng, đi kèm với sự gia tăng phụ thuộc và thay đổi kiến trúc. Vendor lock-in là điều không thể tránh, và khi thay thế sẽ kéo theo gánh nặng viết lại lượng lớn code.
- Vì vậy, thay vì lặp đi lặp lại các quyết định như vậy, chọn ngay từ đầu một nền tảng all-in-one sẽ hiệu quả hơn
- Điều quan trọng là phần mềm mà nhà phát triển thực sự muốn tạo ra
- Các nền tảng tích hợp như Cloudflare, Supabase cung cấp database, queue, image, storage trong cùng một môi trường, qua đó giảm mạnh các loại thuế được nhắc ở trên.
- Không cần chuyển đổi qua lại giữa nhiều vendor (context switching)
- Giảm tần suất phát sinh vấn đề thao tác với API key
- Tối thiểu hóa nhu cầu quản lý tương thích và tách nhánh cấu hình theo từng môi trường
- Cung cấp trải nghiệm tích hợp nhất quán giữa môi trường phát triển và production
- Những nền tảng như vậy tạo cảm giác như mọi thứ đang chạy trên cùng một máy, giảm tối đa khoảng cách giữa code và dịch vụ, giúp lấy lại trạng thái tập trung phát triển ("Flow") mà không SaaS nào có thể mang lại.
> Điều quan trọng không phải là chọn framework hay dịch vụ nào, mà là bảo vệ phần mềm bạn muốn xây dựng và luồng làm việc (Flow) của mình
2 bình luận
Supabase đang được nêu như một ví dụ hay; vậy thì những dịch vụ SaaS nào sẽ là các dịch vụ nên tránh?
Ý kiến trên Hacker News
Đây là góc nhìn xem đây như một hình thức mở rộng cực đại trong thời hiện đại của khái niệm “rent seeking” của Adam Smith
Tôi cho rằng kiểu hành vi kinh tế này có hại cho xã hội nên cần bị tránh và thậm chí nên bị hình sự hóa
Mặt khác, cực đoan theo hướng phần mềm miễn phí cũng có vấn đề về kinh tế, vì nỗ lực của người tạo ra phần mềm không tỷ lệ với giá trị mà người dùng nhận được
Cần tách riêng việc mua phần mềm và ký hợp đồng dịch vụ, để mỗi bên thực sự cung cấp một giá trị độc lập
Vấn đề của SaaS là những thứ đó bị gộp lại làm một, khiến phần “đóng gói” bị méo mó quá mức so với chính dịch vụ thực tế
Nếu tôi nhiệt huyết đến vậy, thì nên tự xây SaaS, lập công ty triển khai và vận hành on-premise, rồi cung cấp với mức giá tương tự SaaS hiện tại
Nếu có thể vừa giúp doanh nghiệp giữ quyền kiểm soát dữ liệu và tránh vendor lock-in, vừa cung cấp chất lượng, bảo đảm và mức giá ngang SaaS, thì có thể thống trị thị trường
Tôi luôn nghĩ về chuyện này: hay là chỉ cung cấp binary và để người dùng tự chạy trên AWS, GCP hoặc Cloudflare Workers?
Với tôi, saas hấp dẫn ở góc độ nhà phát triển nhưng lại đáng ghét ở góc độ người tiêu dùng, nên tôi rơi vào một tình thế tiến thoái lưỡng nan về đạo đức
Nếu tôi bán phần mềm, rồi người dùng tự ý phân phối lại thì sao? Tôi sẽ không thể kiểm soát việc phân phối như saas
Tôi là người ủng hộ foss (mã nguồn mở), nhưng đúng như bạn nói, cách này cũng có vấn đề về kinh tế
Tôi cũng nghĩ tới kiểu cấp license thông qua GitHub Sponsors, hoặc ở một số dự án thì để xác thực theo SSPL, còn nếu mua license thì chuyển sang BSD/MIT, tương tự mô hình Redis trước đây
Tuy nhiên, tôi vẫn nghi ngờ liệu khi áp dụng trực tiếp mô hình này thì mọi người có thực sự mua hay không; tôi cũng đang cân nhắc hỗ trợ cả hai cách, nhưng chưa có câu trả lời rõ ràng nên muốn xin lời khuyên
Tham khảo thì các dự án tôi làm gồm có: công cụ cho phép bất kỳ ai tạo tiền mã hóa miễn phí, tính năng lấy blog từ YouTube, kho lưu trữ không giới hạn dùng YouTube Community và video như một giải pháp thay thế Google Photos, và tôi cũng đang suy nghĩ về việc tăng cường quyền riêng tư. Nếu có ý tưởng kiếm tiền thì mong được chia sẻ
Cần lưu ý rằng với phần lớn SaaS, phía nhà cung cấp phải gánh các chi phí liên tục như hosting, hỗ trợ, R&D
Vì thế tôi khó đồng tình với lập luận cho rằng cấu trúc này là “rent seeking”
Không phải mọi SaaS đều là rent seeking; điểm đáng nói là bản thân “stickiness” của phần mềm đã có bản chất gần với rent-seeking
Phần lớn công ty SaaS đều theo đuổi stickiness, nhưng đó không phải đặc tính riêng có của SaaS
Tôi là người đang bán sản phẩm SaaS của mình cho những khách hàng sẵn sàng mua nó ở mức giá hợp lý trên thị trường
Vendor lock-in thường được cảm nhận khi trong nội bộ công ty có người hỏi “tại sao không triển khai công cụ NEWTHING?”, và câu trả lời là vì đã ký hợp đồng dài hạn 5 năm với Oracle, MS, IBM hoặc Salesforce nên không còn cách nào khác
Rồi sau khoảng 10 năm, bạn thực sự bị trói chặt vào nhà cung cấp đó và không thể đổi được nữa
Nếu doanh nghiệp của bạn tồn tại được tới 10 năm thì đó có khi còn là một điều may mắn hoặc một vấn đề “nhàm chán”
Tôi muốn khuyên các startup giai đoạn đầu là đừng tốn quá nhiều thời gian chọn công cụ, hãy nhanh chóng chọn một nền tảng và tập trung vào nó
Ngay cả trong trường hợp này, vẫn nên trừu tượng hóa các dịch vụ thông qua giao diện chuẩn hóa
Nếu đã trừu tượng hóa sẵn, sau này muốn chuyển sang dịch vụ khác thì chỉ cần cung cấp một implementation thay thế
Đây là cách làm hướng tới tương lai, nhưng hiện nay nhiều công ty vẫn chưa chuẩn bị tốt cho việc đó
Tôi nghĩ việc giảm thiểu phụ thuộc là một trong những yếu tố quan trọng nhất để nâng cao tính bền vững của sản phẩm và doanh nghiệp
Ở công ty cũ, tôi từng phụ trách tích hợp trải nghiệm chữ ký điện tử kiểu DocuSign vào sản phẩm của chúng tôi
Chúng tôi đã trao đổi với các nhà cung cấp lớn như DocuSign, Adobe, nhưng cảm thấy do API bị hạn chế quá nhiều nên không phù hợp với nhu cầu của sản phẩm và khách hàng, cuối cùng quyết định tự triển khai nội bộ
Thông thường, tự làm một công cụ như DocuSign là một quyết định tệ, nhưng vì sản phẩm của chúng tôi vốn đã có được niềm tin từ khách hàng nên rào cản triển khai thấp hơn
Ban đầu khối lượng công việc khi tự làm là khá lớn, nhưng khi cần những điều chỉnh nhỏ thực sự sát với nhu cầu khách hàng thì chúng tôi phản ứng rất nhanh; nếu dùng vendor thì có lẽ đã thành một cuộc đại tu phức tạp hơn nhiều, nên quyết định tự triển khai là đúng đắn
Tôi hiểu tác giả đang nói rằng SaaS là vendor lock-in nên không nên mua
Nhưng ngay trong bài lại khuyến nghị all-in vào một nền tảng cụ thể là Cloudflare
Rốt cuộc chọn kiểu nào cũng đều là lock-in cả; ngay cả mã nguồn mở hay self-hosting, nếu thay thế thì vẫn có thể phải viết lại hàng đống code
Việc chỉ đơn giản dùng một tính năng phụ thuộc vào vendor khác với “lock-in thật sự”; lock-in xảy ra khi chi phí và thời gian để thay đổi còn lớn hơn việc tiếp tục giữ nguyên cách cũ
Nếu phần mềm được ghép nối lỏng và có tính kết dính tốt, thì việc thay thế từng phần cụ thể sẽ dễ hơn
Bởi vì khi interface đơn giản thì thay thế cũng đơn giản
Vì vậy, lựa chọn kiểu “đằng nào cũng lock-in nên cứ trói hẳn vào một nền tảng” có thể tiện cho nhà phát triển, nhưng lại là chiến lược tệ ở góc nhìn quản lý, và điều cần tập trung là tính linh hoạt cũng như khả năng thay đổi của công ty
Ở góc độ người làm kinh doanh, cần chọn giải pháp mang lại cho công ty sự linh hoạt và khả năng thay đổi; bị trói vào SaaS mà không có phương án thay thế thì là điều ngớ ngẩn
Ở giai đoạn bắt đầu hoặc chưa có doanh thu, dùng platform có lợi hơn SaaS; còn khi tăng trưởng và bước vào giai đoạn mở rộng, thì đúng là nên nghĩ tới cả thay đổi công nghệ dài hạn
Tôi dùng Cloudflare Workers khá thường xuyên và cũng đang viết code theo hướng có thể port đi bất cứ đâu
Có thể chạy local bằng
wrangler dev, và thực tế cũng chạy được trên pure node/bun/deno mà không cần sửa nhiềuOP (người viết bài gốc) không phản đối bản thân SaaS (rốt cuộc vẫn đề xuất các giải pháp as a service như Cloudflare hay Supabase), mà điểm chính là chỉ ra chi phí vận hành và gánh nặng quản lý quan hệ khi phải ký và quản lý quá nhiều nhà cung cấp
Càng ít vendor, càng ít phụ thuộc thì vận hành càng dễ
Đúng là việc triển khai mọi thứ chỉ bằng thư viện chuẩn nghe rất lý tưởng, nhưng trên thực tế thì cực kỳ khó
Điểm cốt lõi là khi bắt đầu, thay vì trộn nhiều dịch vụ với nhau thì hãy thử dùng một nền tảng
Lý do tôi thích Cloudflare là vì họ chuẩn hóa binding theo kiểu
fetch, khiếnfetchtrong thế giới web mang lại cảm giác giống như Unix pipesCó một sự mỉa mai ở đây: để tránh vendor lock-in mà lại all-in toàn bộ vào một platform, tức là tự trói mình còn chặt hơn vào một công ty duy nhất
Vì SaaS cũng có chi phí phân tán kiểu “thuế” riêng
Tôi cho rằng thảo luận này thực ra gần với việc ủng hộ mã nguồn mở hơn
Nếu dùng mã nguồn mở và self-host, thì phần lớn các “loại thuế” được nhắc tới trong bài (chi phí khám phá, đăng ký, tích hợp, phát triển local) sẽ được giải quyết
Tôi nghĩ production tax của mã nguồn mở có thể được xử lý bằng một hệ sinh thái sôi động, plugin và hệ sinh thái module
(Ví như sự khác nhau giữa tôn giáo và giáo phái) nếu bạn có thể xuất dữ liệu của mình ra ở định dạng chuẩn rồi rời đi, thì đó không phải vendor lock-in
Khi khách hàng có thể lấy dữ liệu của chính họ, họ sẽ ít cảm thấy bị xâm hại hơn, nhưng vấn đề là quá nhiều dịch vụ SaaS hiện nay lại không cho phép điều đó
Hiện tại tôi chủ yếu phát hành công khai theo MIT, còn những phần quan trọng thì giữ kín
Hạn chế của SaaS là nó khiến khách hàng không thể hưởng lợi đầy đủ từ “chi phí cận biên gần như bằng 0” của phần mềm
Nhà cung cấp SaaS có phản ánh một phần lợi ích đó vào giá thấp hơn, nhưng khi số người dùng đủ lớn và đơn giá đủ cao thì cuối cùng bên dùng SaaS sẽ chịu thiệt
Tuy nhiên, ở giai đoạn đầu của startup, tự xây mọi thứ là một lựa chọn liều lĩnh, và ở giai đoạn “sống sót” cũng như “tối thiểu hóa chi phí ban đầu”, SaaS là chiến lược cực kỳ khôn ngoan
Chỉ sau khi doanh nghiệp phát triển và SaaS đã ăn sâu vào vận hành hằng ngày thì các vấn đề lock-in, di chuyển và chi phí chuyển đổi mới xuất hiện
Tôi nghĩ vấn đề của SaaS, suy cho cùng, cũng chỉ là tác dụng phụ của thành công
Đó cũng là lý do có quá nhiều mô hình SaaS như vậy
Một mô hình kinh doanh vừa tạo ra doanh thu lặp lại như lương hưu, vừa nắm được quyền định giá thì quá hấp dẫn