Trả lời nhanh: Nhu cầu tìm giải pháp thay thế Firebase thường đến từ hai lý do: chi phí tăng khó đoán theo lượng dùng, và dữ liệu người dùng nằm ngoài tầm kiểm soát. Tin tốt là phần lớn thành phần đều có bản tự vận hành: database, xác thực, lưu trữ file, thông báo đẩy. Phần tốn công nhất không phải kỹ thuật mà là đồng bộ ngoại tuyến, thứ mà Firebase làm rất tốt và tự dựng lại rất mất công. Chuyển từng phần một, đừng chuyển một lượt.
Firebase giúp đội nhỏ đi từ ý tưởng tới sản phẩm rất nhanh, và đó là lý do nó phổ biến. Câu hỏi rời đi thường xuất hiện muộn hơn, khi hóa đơn tăng theo lượng người dùng hoặc khi khách hàng doanh nghiệp hỏi dữ liệu đang nằm ở đâu. Bài này liệt kê từng thành phần và mức độ khó khi thay.
Thành phần nào thay dễ
Database. Một database quan hệ chạy trên máy chủ của bạn thay được phần lớn nhu cầu, và với nhiều ứng dụng thì nó còn hợp hơn vì dữ liệu vốn có quan hệ rõ ràng. Cách chọn nằm ở bài Postgres và MySQL.
Lưu trữ file. Một dịch vụ lưu trữ đối tượng tự vận hành, hoặc đơn giản là thư mục trên máy chủ kèm bản sao lưu, phục vụ tốt cho phần lớn ứng dụng.
Hàm chạy theo sự kiện. Thay bằng các điểm cuối API thông thường cộng hàng đợi công việc, theo cách trong bài về hàng đợi.
Xác thực. Có nhiều thư viện chuẩn cho việc này, và phần đăng nhập bằng tài khoản mạng xã hội cũng có gói sẵn. Chi tiết nằm ở bài riêng trong cụm này.
Thành phần nào tốn công
Đồng bộ ngoại tuyến. Đây là phần khó nhất và cũng là thứ Firebase làm thật sự tốt: ứng dụng ghi dữ liệu khi mất mạng, tự đồng bộ khi có mạng lại, và giải quyết xung đột khi hai thiết bị cùng sửa. Tự dựng lại phần này tốn nhiều tháng và rất dễ sai. Nếu ứng dụng của bạn phụ thuộc nặng vào nó, hãy cân nhắc rất kỹ trước khi rời.
Cập nhật thời gian thực. Dễ hơn phần trên nhiều, dùng kết nối hai chiều là được, nhưng bạn phải tự lo phần mở rộng khi số kết nối tăng.
Thông báo đẩy. Phần gửi tới thiết bị vẫn phải đi qua dịch vụ của Apple và Google, không có đường vòng. Cái bạn tự làm được là tầng quản lý danh sách thiết bị và lên lịch gửi, chủ đề của một bài riêng trong cụm này.
Phân tích hành vi người dùng. Có công cụ tự vận hành, nhưng đừng đánh giá thấp công sức duy trì một hệ thống phân tích khi lượng sự kiện lớn.
Tính chi phí cho thật
So sánh chỉ đúng khi bạn tính đủ ba khoản, không chỉ tiền thuê máy:
- Hạ tầng. Máy chủ chạy ứng dụng và database, cộng nơi lưu bản sao lưu.
- Vận hành. Cập nhật hệ điều hành, theo dõi, xử lý khi có sự cố. Với đội đã quen quản trị thì đây là vài giờ mỗi tháng, với đội chưa quen thì nhiều hơn.
- Thời gian chuyển đổi. Khoản một lần nhưng thường lớn nhất, và hay bị ước lượng thấp.
Đổi lại, bạn được ba thứ: chi phí cố định dễ dự toán thay vì tăng theo lượt dùng, dữ liệu nằm trên hạ tầng bạn kiểm soát và đặt được trong nước, và không bị giới hạn bởi mô hình dữ liệu của một nền tảng.
Điểm thứ hai đáng giá hơn tiền với những đội bán cho khách hàng doanh nghiệp hoặc cơ quan nhà nước, nơi câu hỏi dữ liệu đặt ở đâu là câu hỏi bắt buộc trong hồ sơ.
Lộ trình chuyển từng phần
Đừng viết lại một lượt. Thứ tự theo rủi ro tăng dần:
- Lưu trữ file trước. Ít rủi ro nhất, chỉ là đổi nơi cất và đổi đường dẫn.
- Hàm chạy theo sự kiện. Chuyển thành điểm cuối API trên máy chủ của bạn, chạy song song một thời gian để đối chiếu kết quả.
- Database. Phần nặng nhất. Chạy song song, ghi vào cả hai nơi, đọc từ nơi mới, và chỉ tắt bên cũ khi đã yên tâm.
- Xác thực. Để cuối vì nó chạm tới toàn bộ người dùng. Cần kế hoạch chuyển mật khẩu hoặc buộc đặt lại, và phải báo trước cho người dùng.
Trong suốt quá trình, giữ một lớp trung gian trong mã nguồn để phần còn lại của ứng dụng không biết dữ liệu đang tới từ đâu. Nhờ vậy bạn đổi bên dưới mà không phải sửa khắp nơi, và quay lui được nếu có chuyện.
Khi nào nên ở lại
Nói cho công bằng, có những trường hợp rời đi là sai:
- Ứng dụng phụ thuộc nặng vào đồng bộ ngoại tuyến. Tự dựng lại tốn nhiều tháng và rủi ro cao.
- Đội quá nhỏ và chưa có ai quản trị máy chủ. Thời gian bỏ ra để học và vận hành có thể lớn hơn khoản tiết kiệm.
- Sản phẩm còn đang tìm hướng. Ở giai đoạn này, tốc độ ra tính năng quan trọng hơn chi phí hạ tầng.
- Lượng người dùng còn nhỏ. Ở mức thấp, chi phí nền tảng sẵn có thường rẻ hơn một máy chủ riêng.
Mốc thực dụng để cân nhắc lại: khi hóa đơn hằng tháng vượt giá thuê một máy chủ đủ mạnh, hoặc khi có khách hàng đặt câu hỏi về nơi lưu dữ liệu. Trước hai mốc đó, tập trung vào sản phẩm là quyết định đúng.
Thành phần nào thay dễ, thành phần nào tốn công
| Thành phần | Độ khó thay | Ghi chú |
|---|---|---|
| Cơ sở dữ liệu | Dễ tới trung bình | Nhiều lựa chọn tự host trưởng thành |
| Lưu trữ tệp | Dễ | Nhiều lựa chọn tương thích chuẩn phổ biến |
| Xác thực người dùng | Trung bình | Phải chuyển được mật khẩu đã băm, nếu không người dùng phải đặt lại |
| Thông báo đẩy | Khó | Phụ thuộc hạ tầng của hãng điện thoại, khó thay hoàn toàn |
| Phân tích hành vi người dùng | Trung bình | Có lựa chọn tự host |
| Chức năng chạy theo sự kiện | Trung bình | Viết lại thành dịch vụ thường |
Dòng thông báo đẩy là ranh giới thật: phần gửi thông báo tới điện thoại phụ thuộc hạ tầng của hãng, nên bạn thay được lớp quản lý nhưng không thay được lớp truyền. Đừng lập kế hoạch chuyển hoàn toàn ở phần này.
Cộng đủ cả hai phía trước khi so
# Cong day du ca hai phia, dung chi so tien may chu: # Phia dich vu san co:# chi phi theo muc dung trong 3 thang gan nhat# xu huong tang theo so nguoi dung # Phia tu kiem soat:# tien may chu# thoi gian van hanh: cap nhat, sao luu, xu ly su co# uoc 4 den 8 gio moi thang khi on dinh# thoi gian chuyen doi mot lan: thuong tinh bang tuan # Diem hoa von thuong den khi so nguoi dung du lon# va tang deu. Voi ung dung moi chua co nguoi dung,# dich vu san co gan nhu luon re hon.Chuyển lưu trữ tệp trước, cơ sở dữ liệu sau
- Bắt đầu bằng lưu trữ tệp, phần dễ nhất và ít rủi ro nhất.
- Rồi tới cơ sở dữ liệu, chạy song song một thời gian trước khi cắt.
- Xác thực người dùng làm sau, vì đây là phần chạm trực tiếp tới trải nghiệm người dùng.
- Thông báo đẩy và phần phụ thuộc hạ tầng hãng: cân nhắc giữ nguyên.
- Đừng chuyển tất cả trong một lần. Mỗi phần chuyển xong phải chạy ổn định vài tuần trước khi làm phần tiếp.
Còn ít người dùng thì đừng đụng hạ tầng
- Ứng dụng còn ít người dùng và đang tìm thị trường. Thời gian nên dành cho sản phẩm, không cho hạ tầng.
- Đội không có ai vận hành máy chủ.
- Lý do chính đáng nhất để chuyển thường không phải chi phí mà là yêu cầu về vị trí dữ liệu, hoặc cần thứ dịch vụ đó không cho.
Câu hỏi thường gặp
Tự vận hành có rẻ hơn thật không?
Rẻ hơn khi lượng người dùng đã lớn và chi phí theo lượt dùng vượt giá thuê máy. Ở giai đoạn đầu thì thường đắt hơn nếu tính cả thời gian của đội. Hãy so bằng tổng chi phí gồm cả công vận hành.
Phần nào khó thay nhất?
Đồng bộ ngoại tuyến. Đó là phần nền tảng sẵn có làm rất tốt và tự dựng lại thì tốn nhiều tháng, dễ sai ở chỗ giải quyết xung đột. Nếu ứng dụng của bạn dựa nặng vào nó thì hãy cân nhắc kỹ.
Có thể dùng lẫn cả hai không?
Được và nhiều đội làm vậy trong giai đoạn chuyển tiếp: giữ phần khó thay ở nền tảng cũ, chuyển database và lưu trữ file về máy chủ của mình. Đây cũng là cách giảm rủi ro tốt.
Cấu hình máy chủ nào để thay thế?
Bắt đầu bằng 4 vCPU và 8GB cho ứng dụng cùng database ở quy mô vừa, ổ NVMe để database phản hồi nhanh. Đặt trong nước nếu người dùng ở Việt Nam, vì độ trễ ảnh hưởng trực tiếp tới cảm giác của ứng dụng.