Startup có thật sự cần hạ tầng đám mây phức tạp?
(hadijaveed.me)- Với startup giai đoạn đầu, thay vì trang bị Kubernetes hay tự động mở rộng ngay từ ngày đầu, có thể tốt hơn nếu dành thời gian để xây dựng sản phẩm và tìm product-market fit
- 20~30 hàm Lambda cùng log rải rác trong SQS và CloudWatch đã khiến việc debug, thay đổi và triển khai trở nên khó khăn; trong khi vẫn có thể đơn giản hóa bằng một container NodeJS duy nhất hoặc ứng dụng Flask/FastAPI với Redis
- Trong trường hợp tách CRUD và business logic thành 7 microservice chạy trên EKS, thời gian dành cho vận hành hạ tầng lại nhiều hơn phát triển tính năng
- Ngay cả một VM đơn lẻ cũng có thể cung cấp đủ năng lực tính toán cho dịch vụ giai đoạn đầu nếu dùng các lựa chọn như EC2, GCP VM, Hetzner, latitude.sh và máy chủ cỡ 40GB RAM·đa lõi
- Dù cấu hình đơn giản, vẫn cần có HTTPS, SSH/SSM bị giới hạn, CI/CD, DNS, sao lưu DB, VM chờ, khôi phục thảm họa, quy tắc bảo mật và chính sách lưu giữ bản sao lưu để có thể dùng trong thực tế
Hạ tầng quá mức xuất hiện ở startup giai đoạn đầu như thế nào
- Pieter Levels được nhắc đến như một ví dụ vận hành nhiều micro-SaaS trên một máy chủ duy nhất, tránh được độ phức tạp của hạ tầng đám mây và tập trung vào product-market fit
- Cách làm này không phải đáp án phù hợp cho mọi đội ngũ, nhưng cho thấy rõ tình huống triển khai và quản lý hạ tầng trở nên phức tạp chỉ vì chính sự phức tạp
- Với đội phát triển nhỏ sau giai đoạn MVP, việc triển khai và quản lý cơ sở dữ liệu có thể là thách thức, nhưng không phải dự án nào cũng cần Kubernetes, hệ thống phân tán phức tạp hay tự động mở rộng ngay từ ngày đầu
- Hạ tầng đơn giản giúp đội ngũ dành nhiều thời gian hơn để làm ra sản phẩm tốt và tìm được độ phù hợp với thị trường
- Các công ty quy mô enterprise có những vấn đề riêng như tuân thủ và nhân sự quy mô lớn, nhưng startup giai đoạn đầu không nhất thiết phải sao chép nguyên độ phức tạp đó
Trường hợp thực tế: gánh nặng vận hành do sự phức tạp tạo ra
-
Quá tải Lambda
- Có 20~30 hàm Lambda cho các dịch vụ khác nhau
- SQS và nhiều tác vụ nền cũng được xây dựng dựa trên Lambda
- Log phân tán khắp CloudWatch khiến việc truy vết nguyên nhân trở nên khó khăn
- Debug rất vất vả, thay đổi khó khăn và triển khai trở nên phức tạp ngay cả trong monorepo
- Hoàn toàn có thể đơn giản hơn bằng một container NodeJS duy nhất hoặc ứng dụng Python Flask/FastAPI, cùng các tác vụ nền dựa trên Redis
-
Lạm dụng microservice
- Có 7 microservice nhỏ chạy trên Kubernetes EKS
- CRUD và business logic được tách thành các service riêng biệt
- Kubernetes rất mạnh, nhưng đội ngũ đó lại dành nhiều thời gian cho hạ tầng hơn là phát triển tính năng
- Vẫn còn là dấu hỏi liệu ở quy mô đó có thực sự cần mức độ chia tách dịch vụ như vậy hay không
Vì sao cách tiếp cận một máy chủ duy nhất là thực tế
- Cấu hình máy chủ đơn là cách tận dụng tối đa hiệu năng của VM hiện đại
- Có thể tìm được VM mạnh với chi phí hợp lý từ Hetzner và latitude.sh
- Các instance GCP VMs và EC2 cũng có mức giá hợp lý
- Một máy chủ với 40GB RAM và nhiều lõi có thể là lựa chọn tốt hơn nhiều dịch vụ phân tán, nhiều Lambda hay nhiều ECS task
- Mọi thứ tập trung ở một nơi nên việc vận hành và quản lý trở nên dễ dàng hơn
- Việc mở rộng lên hàng triệu QPS chỉ cần xử lý khi thời điểm đó thực sự đến, và khi ấy nhiều khả năng đã có đội hạ tầng riêng
- Để vận hành ổn định một VM đơn lẻ, vẫn cần những thành phần vận hành cơ bản
- Máy chủ vững chắc như EC2, GCP VM, Hetzner
- Truy cập an toàn như HTTPS cho web, SSH giới hạn IP hoặc SSM cho triển khai
- CI/CD để triển khai không gián đoạn
- Thiết lập DNS
- Sao lưu cơ sở dữ liệu định kỳ
- VM chờ để dự phòng
- Cần chiến lược khôi phục thảm họa vững chắc và thời gian khôi phục trung bình đã được kiểm chứng; có thể đạt được bằng VM sao lưu
Docker Compose và Docker Compose Anywhere
- Docker Compose rất tiện để quản lý nhiều service bằng một lệnh trong môi trường phát triển cục bộ, nhưng ít được dùng hơn trong production
- Docker Swarm được nhắc đến là đã deprecated
- Docker Compose có thể gây downtime khi cập nhật
- Có hướng dẫn triển khai production, và cần cân bằng giữa tính đơn giản với mức độ sẵn sàng cho production
- Docker Compose Anywhere là một dự án cuối tuần nhằm đơn giản hóa hơn nữa cấu hình VM đơn
- Thiết lập máy chủ Linux chỉ với một cú nhấp bằng GitHub Actions
- Hỗ trợ continuous deployment không downtime bằng GitHub Container Registry và Docker Rollout
- Cung cấp quản lý biến môi trường và secret; đang cân nhắc age hoặc sops để cải thiện bảo mật
- Cung cấp sao lưu Postgres tự động dựa trên GitHub Actions
- Hỗ trợ nhiều ứng dụng trên một VM duy nhất
- Tự động hóa SSL bằng Traefik và Let’s Encrypt
- Có thể triển khai các ứng dụng Next.js, Go, Python, Node.js...
Nguyên tắc bảo mật và vận hành không thể thiếu dù hệ thống đơn giản
- Bảo mật và bảo vệ dữ liệu không thể bị lược bỏ ngay cả với cấu hình đơn giản
- Cần quy tắc tường lửa nghiêm ngặt, chỉ mở các cổng cần thiết
- Quản lý khóa SSH an toàn; trên AWS ưu tiên SSM, trên GCP ưu tiên CLI
- Có thể dùng bastion host để tăng cường bảo mật
- Bảo vệ secret và cân nhắc dùng WAF hoặc Cloudflare
- Gửi bản sao lưu cơ sở dữ liệu đã mã hóa lên S3 hoặc dịch vụ lưu trữ đám mây an toàn tương đương
- Tạo snapshot đĩa định kỳ để tăng thêm dự phòng
- Triển khai chính sách lưu giữ cho bản sao lưu và snapshot
- Ưu tiên của kỹ sư là giữ sự đơn giản trong cấu hình và tập trung vào sản phẩm cốt lõi
- Cấu hình phức tạp mô phỏng cách làm của Google Engineering hay các tập đoàn lớn, cùng các công cụ mới, rất dễ khiến sự chú ý bị phân tán
- Dù là startup hay không, điều quan trọng nhất vẫn là trò chuyện với người dùng và tìm ra product-market fit
1 bình luận
Các ý kiến trên Hacker News
Tôi từng nhiều lần đổ mồ hôi sôi nước mắt trong nhiều dự án vì công nghệ theo trào lưu
Dù quy mô đội ngũ nhỏ, họ vẫn thường tạo ra những sản phẩm có chất lượng thấp đến khó tin với lý do cần “khả năng mở rộng vô hạn”, và cũng có những đội non kinh nghiệm, thậm chí không hiểu đúng LTS là gì, lại quyết định rằng mình cần Kubernetes
Hiện tôi có một đoạn mã Puppet gọn gàng, có thể tạo VM được harden với kích cỡ mong muốn trên bất kỳ nhà cung cấp nào, rồi chạy Docker service, backend Python hoặc phục vụ file tĩnh trên đó
Dù là VM Hetzner 2 core hay 48 core, tôi có thể dựng dịch vụ trong vòng 5 phút, kiểm soát cấu hình bằng manifest được quản lý trong source control, và giám sát mức độ tuân thủ cấu hình bằng plugin Naemon tùy chỉnh
Đây là một quy trình hoàn toàn có thể tái lập, vậy mà các đội startup vẫn tạo ra những cấu hình dùng một lần kiểu “bông tuyết” trên cloud, chi hàng nghìn euro mỗi tháng nhưng kết quả còn kém hơn những gì các nhà tiên phong DevOps năm 2017 từng làm
Tôi cũng đã viết một bài về chủ đề này tên The Emperor's New clouds: https://logical.li/blog/emperors-new-clouds/
Tôi chưa bao giờ hiểu câu hỏi “làm sao tái lập cấu hình nếu không có Docker hay công nghệ khác”
Script mang tính xác định, phiên bản dependency được ghim cố định, cấu hình, tham số đầu vào và thứ tự thực thi cũng giống nhau, và chạy trên thiết bị tính toán xác định
Không có lý do gì để không tái lập được
Thay vì nói có Docker trên VM đã harden, bạn chỉ cần nói có kubelet, và thay vì nhiều “docker services” chắp vá, có thể điều khiển tất cả các VM đó bằng một control plane k8s với chi phí rất thấp
Tôi không thấy cách đó tốt hơn ở điểm nào, mà trái lại còn trông tệ hơn
Hạ tầng cloud tồi là khi cố dùng mọi thứ AWS bán, khiến toàn bộ hạ tầng bị trói vào các tầng trừu tượng quá cao và không thể chuyển sang nền tảng khác
k8s hoàn toàn khác với chuyện đó
Nếu câu trả lời cho bất kỳ điều nào trong số này là “tự làm” hoặc “chỉ cần một script là được”, thì đó chính là lý do k8s có giá trị
Nếu là backend Python, chỉ cần tái lập nguyên xi build script trên VPS:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> xongMuốn mở rộng số instance thì đưa các lệnh này vào bash script
build_my_app.sh, nó đóng vai trò như một Dockerfile mới và có thể cài lên bất kỳ máy chủ nào trong vài chục giâyNếu dùng như IaaS, tôi có thể tạo prototype nhanh hơn nhiều so với các cách khác, kể cả VPS của nhà cung cấp khác
Đặc biệt Google Cloud có ít hiệu ứng khóa chân hơn và cũng phù hợp hơn với nguyên tắc ít gây bất ngờ nhất
Tuy nhiên sau khi đã tạo prototype, cần tự hỏi có nên dựng lại ở nơi rẻ hơn hay không
Việc có thể mở rộng disk gần như vô hạn và có snapshot là điểm tốt, và cloud có thể giúp mở rộng prototype lên đến tải production để đo quy mô thực sự cần thiết
Nhưng nếu dựa vào “phép màu cloud” như Cloud Run, Lambda, thì thời gian học và debug rốt cuộc cũng tốn ngang với làm theo cách cũ
Ở các startup nhỏ, gần như đều làm theo kiểu này
Dù có những phần phức tạp như tự động mở rộng hàng đợi tác vụ có lẫn GPU, nhưng cốt lõi vẫn là nginx, webapp, Postgres, Redis trên một VM duy nhất
Vì là B2B nên lưu lượng cũng gần như không có
Các lập trình viên có thể chạy nguyên cấu hình đó trên laptop Linux hoặc VM Linux ở nền tảng khác, và nếu muốn để demo hay kiểm thử thì mỗi người cũng có thể có VM cloud riêng
Bootstrap hệ thống mới chỉ ở mức check-in khóa SSH rồi chạy shell script
Dễ debug, không phức tạp hay đắt đỏ, và có thể scale dọc khá nhiều trước khi cần scale ngang
Không phù hợp với tất cả mọi người, nhưng tôi nghĩ trước giai đoạn seed thì hoàn toàn hợp lý
Đây là một bước gián tiếp hóa so với cách “check-in khóa công khai”, và người dùng có thể thay khóa của mình mà không cần thay đổi Git
Ngoài ra, dù khá lệch so với mô tả ban đầu, việc cho thuê SSH key xử lý tình huống offboarding tốt hơn nhiều nên rất hay: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
Trong lúc tìm link, tôi cũng thấy tài liệu nói Vault còn cung cấp mật khẩu dùng một lần <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Tuy nhiên tôi thuộc phe kiên định “PasswordLogin no”, nên phần đó thì mỗi người tự cẩn thận khi dùng
Postgres làm được mọi thứ
Với cấu hình như vậy, bạn theo dõi cấu hình và cập nhật của VM thế nào?
Câu trả lời là “không, không cần”
SaaS của tôi ban đầu chạy trên một máy chủ duy nhất, rồi sau khi đạt product-market fit thì chuyển sang nhiều máy chủ
Chúng là máy chủ bare metal của Hetzner, không có microservice và cũng không đụng đến Kubernetes, nhưng có vận hành cơ sở dữ liệu phân tán
Các máy chủ bare metal này mạnh hơn rất nhiều so với máy ảo của nhà cung cấp cloud
Vài năm trước tôi cũng đã tự đo: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
Nhìn chung cách tiếp cận này hiệu quả đến mức phi lý
Không phải xử lý sự phức tạp như Kubernetes, tránh được các lỗi dây chuyền tất yếu trong những hệ thống phức tạp, đồng thời tiết kiệm thời gian phát triển, bảo trì và chi phí máy chủ hằng tháng
Câu hỏi thường gặp là “thế còn scale thì sao”, nhưng bạn còn chưa biết có cần scale hay không, và chỉ với những máy tính mạnh như vậy cùng thiết kế hợp lý, 3–5 máy chủ cũng có thể đi được rất xa
Tất nhiên tôi không có ý nói nên vận hành doanh nghiệp trong tủ đồ ở nhà
Vẫn cần tự động hóa để quản lý máy chủ, và tôi dùng ansible cùng terraform
Nó kích thích sự lạc quan rằng phần mềm sẽ thành công khủng khiếp trong thời gian rất ngắn, và mọi người muốn tin vào điều đó
Không rõ bạn đã đọc bài hay chỉ nhìn tiêu đề
Nếu kéo xuống phần A few considerations ở bên dưới thì sẽ khó mà cười được
Những “vài điều cần cân nhắc” đó là một khối lượng công việc bảo mật đáng kể, đặc biệt nếu bạn lưu trữ hoặc truyền tải thông tin rất nhạy cảm
Trong tình huống như vậy, bạn xử lý các yêu cầu tuân thủ như HIPAA thế nào?
Có hai loại lập trình viên
Một là người nghĩ mình đã thấy hết rồi, và một là người biết mình gần như chưa thấy gì cả
Vì vậy những khẳng định tuyệt đối kiểu này thật mệt mỏi
20% cốt lõi của Kubernetes là những phần như deployment, pod, service, cách xử lý triển khai blue-green, định nghĩa khai báo, tách namespace, và chúng thật sự rất tốt
Nếu chỉ giữ những nền tảng đơn giản này, dùng dịch vụ Kubernetes đám mây được quản lý, và đặt các cơ sở dữ liệu có trạng thái ở ngoài cluster, thì trải nghiệm sẽ rất ổn
Vấn đề bắt đầu khi bị cuốn vào hang thỏ “cloud native” rồi bắt đầu dùng đủ loại hệ thống mã nguồn mở ngách, operator, ambassador, pattern sidecar, v.v.
Những thứ đó dành cho môi trường có nhiều nhóm kỹ thuật độc lập nhưng kết nối với nhau, cùng nhiều ngôn ngữ lập trình khác nhau cùng tồn tại
Trong các cuộc thảo luận kiểu này, tôi cảm thấy mọi người thường đang nói về hai thứ khác nhau
Với tôi, nó chỉ là một cách triển khai đồng nhất, tốt hơn Docker Compose
Tôi chỉ trả rất ít chi phí cho control plane, còn worker là VM thông thường có kubelet
Nhưng với nhiều người, “Kubernetes” dường như lại có nghĩa là đoạn thứ hai ở trên
Hoàn toàn không cần phải dùng nó theo cách đó
Chỉ cần thử thiết lập một cluster k3s và học workload, service, ingress là được
Để thay thế các cấu hình VM và Docker chắp vá tạm bợ thì chừng đó là đủ
99% chỉ cần hoặc muốn thứ ở mức docker-compose++
Triển khai không gián đoạn là mặc định, có một hệ thống cấu hình đơn giản cho replica set hoặc các cơ chế nhân bản/phân tán khác, vậy gần như là xong
Ước gì có thứ gì đó chỉ làm đúng phần đó
Kubernetes thì quá cồng kềnh, còn Docker Compose thì hơi quá cơ bản đối với các yêu cầu production quan trọng
Kubernetes có cả triệu núm vặn và mặt số để tinh chỉnh cho bất kỳ mục đích nào, nhưng tương tự, bạn cũng có thể bỏ qua chúng và chỉ dùng chức năng cốt lõi để giữ mọi thứ đơn giản
Bạn có thể nhanh chóng tạo được một cấu hình có triển khai ổn, log và metric rất dễ dùng, cùng trải nghiệm lập trình viên tốt
Vì danh tiếng của nó quá tệ và trước đây tôi cũng chưa từng dùng, nên khi hỏi liệu có thể thiết lập một server cho công cụ nội bộ không, tôi đã chuẩn bị tinh thần cho tình huống tệ nhất
Thực tế là người đã thiết lập nó hướng dẫn tôi trong 30 phút, giải thích toàn bộ khái niệm rồi cung cấp đủ thông tin để tôi triển khai server, và tôi triển khai mà không gặp vấn đề gì
Việc thiết lập tự động triển khai bằng
git pushcũng xong rất nhanhVới tôi, nó trông như một lựa chọn quá hiển nhiên
Nếu dịch vụ không phải đúng nghĩa chỉ có một cái duy nhất, thì nó dễ dùng hơn nhiều
Tuy vậy tôi không tự tay cài đặt nó, nên có lẽ tiếng xấu đến từ phần đó
Nếu trong CV không có k8s thì ai kiếm được việc mới đây :)
Nghiêm túc mà nói, tôi nghĩ nhiều người cố ý chọn con đường khó để học hạ tầng quy mô lớn
Một lý do phổ biến khác là “nếu có cực nhiều khách hàng thì sẽ dễ hơn nhiều” hoặc “có thể mở rộng động theo nhu cầu”
Tất cả đều hợp lý với người xây dựng, nhưng không hợp lý đến mức đó với nhà sáng lập hoặc CTO chuyên nghiệp
Một số người không quan tâm đến nhu cầu và lịch trình của khách hàng tiềm năng, mà đốt tiền để xây những thứ hào nhoáng vô nghĩa
Nó giống như bạn mang xe đến gara để thay lốp, nhưng thợ vì nhu cầu phát triển bản thân nên muốn lắp hệ thống thủy lực lowrider và nắp mâm xoay, khiến việc đó mất 3 tuần
Tệ nhất là với người tiếp theo, mọi thứ trở nên mơ hồ về bản chất
Không biết một thứ tồn tại ở đó vì thật sự cần thiết, hay chỉ là đồ trang trí lấp lánh
Tôi không rõ mọi người làm vì hứng thú, vì yêu công nghệ, hay như đã nói, vì muốn đưa k8s vào CV nên nâng kỹ năng theo kiểu kỹ trị
Tôi chỉ nghĩ “trông có vẻ đau khổ khi phải quản lý”
Vì vậy tôi nghĩ hạ tầng k8s tốt hơn nên được thiết kế và vận hành bởi nhóm nhỏ hơn gồm những người thật sự thành thạo, hoặc ít nhất là những người đủ kinh nghiệm để dẫn dắt mentee
Còn khi không cần thiết, tức là với phần lớn startup, doanh nghiệp nhỏ và doanh nghiệp quy mô bình thường, thì nên giữ paradigm hiện có dễ dùng hơn
Họ rất hài lòng với lựa chọn này và đã viết chi tiết trên blog
Đây là trường hợp mà “nếu có cực nhiều khách hàng thì sẽ dễ hơn nhiều” thật sự đúng
Đây là một cuộc tranh luận cũ kỹ và thường gây mệt mỏi, nhưng tôi vẫn xin góp 2 xu của mình
Có cần chọn một framework phức tạp ngay từ ngày đầu không? Nếu đội ngũ chưa có đủ kinh nghiệm với nó thì có lẽ là không
Nhưng điều tôi phản đối là suy nghĩ rằng quản lý hạ tầng bằng quy trình tự chế và công cụ tùy biến thì lúc nào cũng tốn ít công bảo trì hơn các công cụ đã được kiểm chứng
Đó là thái độ cố chấp bác bỏ “độ phức tạp” như một người rơm, dù quy trình tự làm hoàn toàn không đơn giản và lấy đi rất nhiều thời gian khỏi sản phẩm cốt lõi
Ai cũng thích sự đơn giản của việc copy binary lên VPS rồi restart service
Nhưng chẳng bao lâu bạn sẽ cần quản lý cấu hình và secret, rồi khi có nhiều server để đảm bảo khả dụng và dự phòng, bạn sẽ cần triển khai dần, cân bằng tải, rollback, v.v.
Bạn cũng sẽ muốn có môi trường staging, và cần dễ dàng nhân bản workflow này
Khi đội ngũ lớn lên, việc không thể chạy một môi trường giống production ở local cũng sẽ lộ ra
Cứ thế các yêu cầu tiếp tục được thêm vào
Cuối cùng, với mỗi yêu cầu mới, thay vì dựa vào lời giải chuẩn mà người khác đã giải quyết, bạn phải giải theo cách đặc biệt của riêng mình
Về sau nó trở thành vấn đề chi phí chìm
Liệu có bỏ những công cụ tùy biến mà bạn biết và hiểu, để chuyển sang một “độ phức tạp” mà bạn không biết không?
Càng đầu tư nhiều thì về sau càng khó chuyển
Đề xuất của tôi là ngay từ đầu hãy tuân theo những thực hành giúp việc chuyển sang công cụ chuẩn sau này dễ hơn
Tức là triển khai bằng container từ ngày 1, áp dụng phương pháp luận 12-factor, đại loại vậy
Và khi bắt đầu khổ sở vì những tính năng cần có, tốt hơn là chuyển sang công cụ đã được kiểm chứng sớm thay vì muộn
Rất có thể bạn sẽ thấy nỗi sợ cái chưa biết là vô căn cứ, và về dài hạn thời gian dành cho hạ tầng sẽ giảm đi
Cách tiếp cận tôi từng cân nhắc là bắt đầu bằng công cụ chuẩn ngay từ ngày đầu, tức k8s + gitops, nhưng vẫn chạy trên một VM duy nhất
Bạn nghĩ sao?
Trong khi đó có thể tìm thấy khá nhiều “cloud engineer” hiểu các hệ thống cloud “phức tạp” kiểu này và có thể triển khai, bảo trì bằng terraform
Đó là một bộ kỹ năng có thể đưa vào làm ngay
VM, lưu trữ block/blob, DNS, IdP, nhà đăng ký tên miền
Trong cloud, những thứ tôi từng dùng một cách thoải mái chỉ đến mức đó
Khi bước sang FaaS và những thứ họ hàng của nó thì với tôi mọi thứ trở nên thật sự kỳ lạ
Tôi khó chấp nhận việc không thể nhìn vào máy đang chạy môi trường production
Trải nghiệm debug qua dashboard cloud rất tệ
Tôi cho rằng cách tiếp cận của Microsoft là gần nhất với việc thực sự “hoạt động”, nhưng nó vẫn thật sự khủng khiếp và tôi không muốn đụng tới lần nữa
Sau 10 năm, kiến trúc lý tưởng của tôi vẫn là một VM duy nhất, nơi một codebase monolithic giao tiếp với các instance SQLite local
Sự xuất hiện của lưu trữ NVMe đã tiếp sức khá nhiều cho cách này
Backup xử lý bằng snapshot thiết bị lưu trữ block, còn độ bền transaction thì nếu cần xử lý bằng WAL replication
Đơn giản đến mức ngớ ngẩn
Nó cho phép tôi tập trung vào doanh nghiệp và khách hàng
Khách hàng hoàn toàn không quan tâm đến những thứ này, và cũng sẽ không trả tiền cho chúng
Toàn bộ code và hạ tầng đều là yếu tố âm thuần túy, nên nên giữ ở mức ít nhất có thể
Khi mọi người nói cloud đắt hơn on-premises, lý do thường là cái này
Nếu định chạy VM 24/7 thì có những lựa chọn tốt hơn
Ngay cả sách về microservices cũng nói rằng hãy xây monolith trước
Trước khi có phản hồi từ người dùng thực, bạn không thể biết nên chia hệ thống như thế nào, và tách một monolith thì dễ hơn tái cấu trúc các service
Có thể bạn sẽ chẳng bao giờ cần tách monolith
Stripe rốt cuộc cũng tách một phần ra khỏi Rails monolith, nhưng monolith có thể đi xa một cách đáng ngạc nhiên
Khó có gì dễ debug hơn một monolith như Django/Rails
Tuy vậy, nhìn trước một chút xem hạ tầng sẽ đi về đâu cũng có ích
Phiên bản ban đầu của công ty chúng tôi được làm bằng container Django Docker trên một VM duy nhất, triển khai thủ công bằng
docker pull; docker stop; docker startCấu hình này trụ được lâu hơn tôi nghĩ
Docker là một cách tốt để né vấn đề đóng gói dependency
Ở giai đoạn đầu, những vấn đề như khi cài driver DB mới thì server có các file header C cần thiết không, hay cấu hình có khác Mac không, có thể khá phiền
Sau vòng gia hạn seed, vì nhu cầu kinh doanh về độ tin cậy và khả năng mở rộng, chúng tôi chuyển sang k8s, và k8s đã trụ tốt đến Series B
Nhờ mọi thứ đã được Docker hóa nên việc chuyển đổi cũng dễ, nhưng ở giai đoạn đầu chúng tôi đã cắt giảm độ phức tạp rất quyết liệt
Và cần dùng framework cho đúng, đừng tự làm lại những phiên bản tệ hại của các tính năng mà framework đã cung cấp
Ở khía cạnh này, một người thành thạo tạo ra kết quả tốt hơn 10 người non tay
Theo thời gian, khoảng cách đó sẽ tích lũy
Tôi nghĩ một nửa lý do thực sự khiến mọi người chán monolith là do những monolith tệ và không được vận hành đúng cách
Nó nói dữ liệu nên được lưu trong service riêng, và nếu cần cách tiếp cận đa mô hình như quan hệ và tìm kiếm toàn văn, có thể sẽ thành nhiều service
Trải nghiệm người dùng cũng nên dùng service riêng
Ít nhất phải có một service khác ở giữa, và thường Django và Rails nằm ở đây
Tùy chọn, có thể cần thêm các service như xác thực, giao dịch tài chính
Tôi đã vận hành một dự án trong khoảng 6 năm trên một VPS 10 đô/tháng duy nhất
Nhờ ưu đãi vĩnh viễn lấy được từ lowendtalk, thực tế tôi trả còn ít hơn, và đó là nhà cung cấp VPS tập trung vào game server
Ngoài một lần downtime cả ngày vì tôi làm hỏng cấu hình nên phải cài lại OS sạch, và một lần nhà cung cấp đổi địa chỉ IP sau khi thông báo trước, độ ổn định gần như ở mức 99.999
Công nghệ VPS đã tiến bộ thật sự rất nhiều và rất ổn định
Đĩa của node được cấu hình RAID 1, và khi bảo trì node, bản thân VM cũng có thể live migrate sang máy khác một cách dễ dàng
Cũng có thể tạo snapshot
Với tôi, lý do chọn hạ tầng cloud có lẽ không phải vì độ ổn định cao hơn, mà vì các tính năng cộng tác và quản trị vận hành như IAM, quản lý secret, infrastructure as code, hoặc vì yêu cầu tuân thủ trung tâm dữ liệu như HIPAA
Tùy tình huống
Cá nhân tôi thích các giải pháp dựa trên cloud vì chúng giúp tiết kiệm rất nhiều thời gian
Tuy nhiên phải rất chọn lọc khi quyết định dùng gì, và cũng có những giải pháp quá phức tạp đến mức rõ ràng phản tác dụng
Tôi đang vận hành một startup bootstrap nhỏ
Chúng tôi còn không đủ tiền để tự trả lương cho mình, còn tôi thì duy trì cuộc sống bằng công việc tư vấn làm thêm
Khi ngân sách và thời gian bị giới hạn như vậy, chúng tôi phải cực kỳ cẩn trọng trong việc chọn dùng gì
Vì thế tôi thích những thứ như Google Cloud
Hóa đơn GCP khá thấp, chỉ vài trăm euro mỗi tháng
Chúng tôi cũng có thể chuyển sang nhà cung cấp rẻ hơn, nhưng khó biện minh cho khoản đầu tư thời gian đó, và so với AWS tôi từng dùng trước đây thì tôi cũng thích UI và công cụ của Google hơn
Kubernetes thì không có việc gì cần dùng
Chỉ riêng chi phí chạy một cluster trống có lẽ đã đắt hơn hóa đơn GCP hằng tháng hiện tại
Chúng tôi cũng không cần đến nó vì không rơi vào cái bẫy microservices
Nhưng tôi thích Docker
Nó khiến việc triển khai phần mềm dễ như đùa
Website của chúng tôi là một bucket Google Storage được phục vụ qua load balancer và Google CDN
Cùng load balancer đó định tuyến các REST call tới hai VM chạy monolith
Các VM này giao tiếp với DB được quản lý, Elasticsearch được quản lý và Redis được quản lý
DB và Elasticsearch thì đắt, nhưng dùng dạng managed giúp tiết kiệm rất nhiều thời gian và công sức
Gần như tất cả những gì chúng tôi có chỉ có vậy, đơn giản và cũng không quá đắt
Nếu chuyển toàn bộ sang nơi như Hetzner thì có lẽ có thể giảm chi phí khoảng 50%
Có thể đáng thử, nhưng với tôi thì không phải việc quá cấp bách
Mất các managed service đó sẽ khiến cuộc sống của tôi khó khăn hơn
Một số khách hàng có vẻ thích AWS hơn, nên một ngày nào đó có thể chúng tôi sẽ phải quay lại AWS, và đó cũng là một yếu tố