Điểm mạnh và yếu của Caprover trong triển khai production

Vừa rồi mình có một thảo luận với team về việc khi nào thì nên sử dụng Caprover để triển khai mô hình production, mình sẽ chia sẻ lại một số góc nhìn của mình khi nào nên sử dụng và không nên sử dụng Caprover: English version: https://vinguyen.blog/what-is-advantages-and-disadvantages-of-caprover-in-production-deployment/

Caprover là gì?

Ngắn gọn: Free and Open Source PaaS! Chi tiết hơn: https://caprover.com/docs/get-started.html

Điểm mạnh và điểm không mạnh của Caprover là gì?

Điểm mạnh:

Caprover là 1 opensource PaaS hoàn chỉnh (Heroku like as opensource) được build dựa trên nền tảng docker swarm & production ready: nghĩa là chúng ta có thể dùng để triển khai tương tự triển khai trên Heroku trên 1/nhiều self-host server: Vì là PaaS nên dễ dàng apply được Twelve-Factor trong mô hình triển khai
Có nhiều giải pháp deployment đơn giản & tiện dụng: CLI, Web UI, Git integration
Mô hình triển khai, roll-out đầy đủ, CI/CD ready để sử dụng
Tận dụng được thế mạnh của Docker/Dockerzied Application vốn đã rất phổ biến trong giới lập trình hiện tại
One-Click App có sẵn nhiều pre-configuration application. on-click to deploy

2. Điểm chưa mạnh

Persistent data: mình đánh giá đây là 1 điểm giới hạn lớn của Caprover, vì chỉ hỗ trợ được persistent data on Disk (Once they get created they get locked down on a specific server (if you have multiple servers).): vì với hạn chế này thì khi muốn triển khai 1 service đòi hỏi Persistent data thì tính horizonal scale của app bị triệt tiêu vì chỉ sử dụng được trên 1 Server, hoặc application phải thiết kế để thành stateless app ngay từ đầu và sử dụng các cơ chế storage khác: vd Blockstorage ( S3/MinIO/Storj,...)
Scaling resource trên multiple nodes (cần kiểm chứng thêm): trong một vài trường hợp trong lúc hỗ trợ team để setup scale 1 Caprover cluster, mình nhận thấy việc autoscaling & cân bằng resource trên nhiều node chưa thật sự tốt, một số case cần phải manually phân bổ resource trên server, với mình thì điểm này vừa là điểm tối ưu ( vì có thể tự tính toán xem nên để service ở đâu là tốt nhất) nhưng lại vừa quá tốn chi phí setup & monitoring, điểm này các orchestration tool khác như k8s cơ chế hoạt động khá mượt mà
Account quản lý & phân quyền trên Caprover: CapRover is not an enterprise grade application like Kubernetes. về cơ bản thì caprover không có goal trở thành enterpise grade application, nên các cơ chế về user, phân quyền, chi sẻ tài nguyên sẽ không được phát triển nhiều, nên nếu bạn có mong muốn sử dụng Caprover trong 1 team nhiều member, có cơ chế phân quyền, hoặc nhiều application/service thuộc nhiều product khác nhau trên cùng 1 Caprover thì gần như không triển khai được.

Vậy Caprover phù hợp và không phù hợp khi nào?

Phù hợp:

Team nhỏ, có thể tin tưởng được và hông cần cơ chế phức tạp product đang ở giai đoạn MVP hoặc early state của insightful product , chưa large scale, traffic vào backend không tăng giảm, độ biến, ...
Lượng service không quá nhiều, persistent data được thiết kế sẵn theo statefull service
Server có khả năng Horizontal và Vertical Scale.
Team có sẵn kinh nghiệm với docker, dockerzied application, muốn triển khai quy trình CI/CD nhanh, tiện, gọn & ready để sử dụng
Có sẵn kinh nghiệm với Nginx, Letsencrypt,...
Quen thuộc với mô hình PaaS như Heroku

Không phù hợp:

Application phức tạp, nhiều service, traffic nhiều, hoặc tăng giảm bất thường ( vd event, e-comerse flash sales)
Team có nhiều product nhưng muốn cùng triển khai trên cùng 1 Caprover, nhưng lại có mong muốn phân chi quyền dữ liệu, tài nguyên.
Các giải pháp triển khai khác có thể sử dụng
Heroku: xịn rồi, trả tiền là được
Docker, docker-compose on Single server: giải pháp này vừa đủ cho các application nhỏ, traffic không quá cao, đơn giản, tiện dụng, dễ đồng bộ & backup, CI/CD cũng có thể triển khai bằng một số kĩ thuật đơn giản
Aws Autoscaling Group/Azure VM Scale Set: giải pháp này thì xịn xò hơn để cho các application có nhu cầu tải cao, hoặc scaling được khi có nhu cầu Kubernetes/K8S: nếu apply được thì tốt, nhưng cồng kềnh và chi phí maintain, chi phí resource nền tảng cao, nên chỉ phù hợp với những application tương đối lớn và team có kinh nghiệm K8S mạnh ( mình sẽ có 1 bài chia sẻ về vấn đề này sau)