Tôi đang xây dựng một đám mây
(crawshaw.io)- Các lớp trừu tượng đám mây hiện nay khiến việc kết hợp CPU, bộ nhớ và đĩa theo cách mong muốn trở nên khó khăn, và cả VM lẫn PaaS đều tạo ra nhiều ràng buộc hơn một máy tính thông thường
- Lưu trữ khối từ xa và chi phí egress cao vẫn duy trì một kiến trúc bị trói buộc bởi các giả định từ thời HDD, đồng thời làm trầm trọng hơn các vấn đề về hiệu năng và chi phí trong môi trường SSD và mạng hiện đại
- Kubernetes che phủ lên trên các API đám mây khó sử dụng, nhưng không thể thay đổi chính lớp trừu tượng nền tảng vốn đã sai, nên vẫn mang theo nguyên vẹn các giới hạn của VM, đĩa và mạng
- Khi nhu cầu về phần mềm và thực thi tăng lên nhờ agents, không gian thực thi riêng tư, khả năng chia sẻ dễ dàng và chi phí vận hành thấp trở nên quan trọng hơn, đồng thời các điểm nghẽn cấu trúc của đám mây hiện tại cũng phình to theo
- exe.dev muốn tiến gần hơn tới kiểu đám mây mà người ta thực sự muốn dùng bằng cách cấp phát CPU và bộ nhớ trước rồi cho phép chạy VM trực tiếp trên đó, kết hợp TLS proxy, proxy xác thực, NVMe cục bộ, sao chép bất đồng bộ và triển khai dựa trên anycast
Vì sao phải xây lại một đám mây mới
- Lớp trừu tượng đám mây hiện tại khiến việc sử dụng máy tính theo cách mong muốn trở nên khó khăn, và đó là lý do trực tiếp để bắt đầu công ty mới này
- Bản thân máy tính thì rất tốt, nhưng đám mây ngày nay lặp lại cùng một kiểu ràng buộc ở gần như mọi sản phẩm, và cốt lõi của vấn đề gần với hình dạng của các đơn vị cấu thành cơ bản hơn là chỉ lỗi UX hay thiết kế API
- VM được cung cấp dưới dạng các instance riêng lẻ gắn chặt với CPU và bộ nhớ, trong khi cấu trúc mong muốn lại gần với việc cấp phát trước tài nguyên CPU, bộ nhớ và đĩa rồi triển khai bao nhiêu VM tùy ý lên trên đó
- Linux VM thực chất là các tiến trình chạy trong cgroup của một Linux khác, nhưng trong đám mây hiện tại điều này không dễ xử lý
- Để lách qua, phải đặt gVisor hoặc ảo hóa lồng nhau lên trên một VM đám mây duy nhất, và cùng với tổn thất hiệu năng còn phải tự gánh ít nhất việc vận hành reverse proxy
- PaaS cũng không giải quyết được vấn đề này, mà còn ép buộc các lớp trừu tượng phụ thuộc nhà cung cấp kém mạnh hơn cả một máy tính thông thường
- Mỗi nhà cung cấp compute lại đòi hỏi học một cách phát triển mới
- Nhiều khi chỉ sau khi dự án đã tiến triển kha khá mới lộ ra rằng một việc rất dễ trên máy tính thông thường lại gần như bất khả thi vì các giới hạn ăn sâu trong nền tảng
- Hết lần này đến lần khác tưởng là “lần này được rồi”, nhưng lại tiếp tục bị chặn bởi các lớp trừu tượng nửa vời
Những giới hạn cấu trúc bộc lộ ở đĩa và mạng
- Ở lớp đĩa, các nhà cung cấp đám mây ưa thích lưu trữ khối từ xa hoặc các mô hình còn hạn chế và chậm hơn như S3, điều này từng có phần hợp lý trong thời HDD
- Lưu trữ từ xa không chịu thiệt hại lớn với đọc/ghi tuần tự, và random seek của HDD ở mức khoảng 10ms nên RTT 1ms qua Ethernet là cái giá có thể chấp nhận
- Từ phía nhà cung cấp, điều này giúp loại bỏ một trục trong các loại instance tiêu chuẩn, nên vận hành dễ hơn
- Nhưng khi chuyển sang SSD, giả định đó sụp đổ
- Thời gian seek giảm từ 10ms xuống còn 20 micro giây
- RTT mạng của các hệ thống khối từ xa có cải thiện, nhưng overhead IOPS từ mức khoảng 10% thời HDD đã tăng lên hơn 10 lần trong thời SSD
- Trên EC2, để cấu hình 200k IOPS thì thiết lập đã phức tạp lại còn tốn 10.000 USD mỗi tháng, trong khi MacBook cung cấp 500k IOPS
- Bản thân công nghệ mạng đã đủ tốt, nhưng chi phí egress và cấu trúc kinh doanh lại vận hành theo hướng cản trở tính khả dụng
- Mạng của các hyperscaler rất xuất sắc nhưng chi phí cực cao và cũng khiến việc liên kết với nhà cung cấp khác trở nên bất tiện
- Đơn giá egress của các nhà cung cấp đám mây được đưa ra ở mức cao gấp 10 lần mỗi GB so với khi rack server trong một data center thông thường
- Chỉ cần mức sử dụng tăng lên đôi chút thì hệ số này còn tệ hơn nữa
- Khách hàng chi hàng chục triệu USD mỗi tháng có thể nhận được giá tốt hơn, nhưng điều đó không phù hợp với các dự án quy mô vài chục hay vài trăm USD mỗi tháng
- Trong khoảng này, dù xây gì đi nữa cũng bị chặn theo hướng khó vận hành với chi phí rẻ
Kubernetes và API che lấp vấn đề nhưng không giải quyết nó
- API đám mây rất đau đớn để làm việc cùng, và Kubernetes xuất hiện theo hướng che phủ lên trên để giảm bớt nỗi đau mà kỹ sư phải chịu
- Nhưng VM vẫn khó xử lý ngay cả trên Kubernetes vì đám mây đang đẩy trực tiếp gánh nặng ảo hóa lồng nhau cho người dùng
- Với đĩa cũng vậy, vào thời Kubernetes được thiết kế, phía Google gần như không có thiết bị khối từ xa nào thật sự dùng được, và ngay cả khi ngày nay có thể miễn cưỡng khớp được mẫu số chung thì cuối cùng vẫn dễ bị trói vào lưu trữ chậm
- Mạng cũng tương tự: nếu mở cho dễ dùng thì có thể nối một phần hệ thống trong data center mở lân cận bằng private link và xóa đi một số 0 trong chi phí đám mây, nên không có nhiều động lực để làm cho dễ
- Thay vì xem Kubernetes là thứ việc vặt giả tạo, nên xem nó như sản phẩm được tạo ra để đối đầu với một bài toán bất khả thi: làm ra một đám mây portable và usable
- Về căn bản, không thể giải quyết vấn đề bằng cách chồng thêm một lớp trừu tượng mới lên trên lớp trừu tượng đám mây vốn đã sai, và cả việc làm cho Kubernetes tốt hơn rốt cuộc cũng có giới hạn rất rõ
- Quãng thời gian sống cùng kiểu đám mây khó chịu này đã lên tới 15 năm, và suốt thời gian đó người viết chỉ cố chịu đựng giống như với các phần khác của một software stack khó ưa, bằng cách tiếp xúc ít nhất có thể
Đây là thời điểm phải sửa nó
- Lý do khiến hiện tại trở thành điểm ngoặt là sự xuất hiện của agents
- Giống như nghịch lý Jevons, viết code càng dễ thì tổng lượng phần mềm lại càng tăng, và mỗi người sẽ dùng nhiều chương trình hơn cả trong công việc lẫn sở thích
- Để chạy khối lượng chương trình ngày càng tăng đó, cần có không gian thực thi riêng tư, khả năng chia sẻ dễ dàng và overhead vận hành nhỏ
- Tổng lượng phần mềm càng tăng thì các vấn đề đám mây trước đây chỉ gây khó chịu sẽ trở thành điểm nghẽn lớn hơn rất nhiều
- Cần nhiều compute hơn và việc quản lý cũng phải dễ hơn
- agents có thể giúp thao tác thay cho AWS API, nhưng phải giao phó thông tin xác thực và đôi khi chúng có thể xóa cả cơ sở dữ liệu production
- Quan trọng hơn, agents cũng đâm vào cùng bức tường giới hạn nền tảng của các lớp trừu tượng đám mây hiện tại như con người
- Chúng tiêu tốn nhiều token hơn mức cần thiết và kết quả cũng tệ hơn kỳ vọng
- Cửa sổ ngữ cảnh của agent càng bị dùng để gò ép cho phù hợp với đám mây kiểu cũ, thì càng ít chỗ cho việc giải quyết vấn đề thực sự
Những phần exe.dev đã bắt đầu sửa trước
- exe.dev trước tiên đã ra mắt giải pháp cho bài toán cô lập tài nguyên VM
- Thay vì provision từng VM riêng lẻ, hệ thống cấp trước CPU và bộ nhớ rồi cho phép người dùng tự chạy các VM mong muốn lên trên đó
- Với giả định rằng không muốn phơi trực tiếp VM mới ra Internet, hệ thống xử lý cả TLS proxy lẫn proxy xác thực
- Đĩa sử dụng NVMe cục bộ, còn các block được sao chép bất đồng bộ ra ngoài máy
- Hệ thống cho phép đặt máy ở nhiều khu vực trên thế giới để có thể chạy ở vị trí gần người dùng
- Các máy được triển khai phía sau mạng anycast để cung cấp điểm vào có độ trễ thấp cho người dùng toàn cầu
- Trên nền tảng này, kiến trúc cũng được thiết kế để sớm bổ sung thêm các tính năng mới
- Vẫn còn rất nhiều thứ phải xây
- Những hạng mục tương đối rõ ràng như IP tĩnh vẫn còn ở phía trước
- Các bài toán như UX để truy cập các snapshot đĩa lịch sử được tạo tự động cũng vẫn còn đó
- Đồng thời, nhóm cũng đang quay lại bước tự rack máy tính trong data center, rà soát lại toàn bộ các tầng của software stack bao gồm cả cách kết nối mạng
- Mục tiêu cuối cùng là tạo ra một đám mây mà người ta thực sự muốn sử dụng
6 bình luận
Ban đầu còn nghĩ là “sao đến giờ này lại làm việc đó nhỉ?”..
Nhưng thấy tác giả là đồng sáng lập Tailscale thì tự nhiên lại muốn ủng hộ
Mong bạn làm thật tốt!
Bảng giá khó hiểu quá, vì nó được ghi kiểu như 2 core 8GB, 50 VM. Có lẽ phải hiểu là cấp 1 VM và có thể chạy 50 container trên đó.
Lý do đám mây phức tạp là vì có lý do của nó.
Mình không thấy chức năng xóa tài khoản, có ai tìm được chưa?
Sẽ thật tuyệt nếu chỉ cần kéo và thả là có thể kết nối các dịch vụ với nhau.
Ý kiến Hacker News
Kubernetes lúc đầu có vẻ ổn nếu chỉ chạy vài container web app, nhưng rồi sớm muộn cũng chồng thêm SDN và đủ loại dịch vụ, thế là phình to mất kiểm soát
Càng "tối ưu hóa" và "hardening" cluster thì chi phí cloud, sự cố, downtime và công sức debug đều tăng gấp 2~3 lần
Cuối cùng họ bỏ quán tính DevOps đó, xóa cluster đi, bật firewall trên một VM Debian đơn lẻ rồi dùng Kamal để deploy Docker, và kết quả là hạ tầng ổn định, đáng tin cậy nhất, đồng thời chi phí cũng giảm mạnh
Phần lớn ứng dụng doanh nghiệp chỉ phục vụ từ vài trăm đến vài nghìn người dùng, nên một VM lớn thường là đủ; còn các cloud như Google đã lo phần sự cố phần cứng rồi, nên chỉ khi cần mới dựng thêm VM thứ hai và đổi IP ở Cloudflare là được
Rất hay có chuyện lôi k8s vào cho những hệ thống quá nhỏ, và nếu như thế thì ngay từ đầu quy mô đó có lẽ chưa cần k8s
Vì vậy cần một lớp cao hơn để đơn giản hóa các mẫu triển khai phổ biến, và Knative là một ví dụ như thế
Bất kỳ giải pháp nào cố phơi bày toàn bộ primitive nền tảng cuối cùng cũng sẽ phức tạp ngang Kubernetes
https://github.com/openrundev/openrun do tôi làm xử lý deployment web app nội bộ cho team theo kiểu khai báo, có cả SAML/OAuth và RBAC, đồng thời hỗ trợ cả Docker một máy lẫn Kubernetes
Kiểu tư duy quá phức tạp, khó debug và tốn tiền đó hoàn toàn có thể tái hiện y hệt trên VM
Chỉ là hiện tại VM Debian đơn lẻ đó đang nằm ngoài tầm radar chính sách của họ nên mới được tự do
Một khi có người khác nhảy vào, rất có thể họ sẽ lại muốn gắn thêm HA, rollout/rollback, 3~5 VM, chính sách mạng ảo, 4 công cụ quét bảo mật, 2 bộ xử lý log, watchdog, giám sát mạng, mTLS, thiết bị quan sát lưu lượng và đủ thứ khác
Có thêm một máy thì khi nâng cấp hay thay đổi mà xảy ra sự cố cũng bớt lo hơn
https://github.com/psviderski/uncloud tôi đang làm, lấy cảm hứng từ Kamal, nhằm biến cấu hình nhiều máy trở nên đơn giản như một VM đơn, dùng WireGuard overlay zero-config và Docker Compose tiêu chuẩn để deploy lên nhiều VM
Có thể bắt đầu từ 1 máy mà không cần độ phức tạp của orchestrator hay control plane, rồi khi cần thì mở rộng bằng cách trộn cloud VM và on-prem
Tôi dùng nó trong production và thấy tuyệt ở mọi khoảnh khắc, gần như ở mức tái định nghĩa lại chính việc tính toán
Nên có lẽ tôi đang bỏ sót góc nhìn của phía ghét nó đến mức này
OP là một trong các đồng sáng lập Tailscale, nên về ngữ cảnh lại càng thú vị hơn
Nhận định rằng các công ty Cloud 1.0 truyền thống mặc định chỉ cho VM khoảng 3000 IOPS trong khi laptop lại đạt 500 nghìn IOPS có vẻ rất chuẩn
Tầm nhìn thì thật sự tốt và tôi có cảm giác mình đúng là khách hàng mục tiêu, nhưng tôi vẫn lo rằng càng thành công thì họ lại đi theo con đường quen thuộc: áp lực lợi nhuận lấn át lý tưởng
Giá cloud nhiều khi không dựa trên chi phí, và đặc biệt thường được thiết kế để kiếm lời mạnh ở những hạng mục chỉ tăng vọt sau khi khách hàng đã bị trói sâu như bandwidth hay NAT gateway
Tôi không nghĩ OP lại không biết cấu trúc này
Nhưng storage đó về cơ bản là ephemeral, và độ dư thừa cũng không đủ
Có thể giảm rủi ro hỏng phần cứng bằng RAID1, nhưng đổi lại số lượng NVMe gắn được sẽ ít đi, và khi cần chuyển VM do các vấn đề khác của host như RAM/CPU thì cũng không có cách nào gọn gàng
Cuối cùng những VM kiểu này gần như phải được đối xử như bare metal, và cần nhân bản ở tầng ứng dụng như replication database
Với Azure thì phải giả định rằng họ có thể di chuyển VM lúc nào họ muốn và làm mất dữ liệu ephemeral; còn trong OpenStack, khi cần có thể tắt VM rồi sao chép cả dữ liệu NVMe sang host khác bằng local block-level migration
Dù vậy, nếu host bị crash thì VM đó vẫn sẽ nằm xuống cho tới khi host sống lại, nên mặc định phải có dự phòng ở tầng ứng dụng
Nhưng độ trễ p99.9 thì Hetzner khoảng 5ms, còn DO khoảng 18ms; độ trễ tối đa là Hetzner 7ms so với DO 85ms, chênh lệch khá lớn
Với dd tuần tự thì Hetzner đạt 1.9GB/s, còn DO là 850MB/s
Giá cũng chênh mạnh: Hetzner 4 euro còn instance của DO là 18 đô
Tôi viết điều này trước khi đọc hết bài, và đúng lúc OP cũng chỉ thẳng chính hai thứ đó
Tức là khiến ngay cả server đơn giản cũng khó dùng DB cục bộ trên máy để tạo lock-in
Kiểu một món đồ tốn X để làm ra nên bán giá 1.y*X thực tế khá xa với cách thị trường định giá
Top-down thực tế hơn bottom-up
Cũng như tranh luận quanh AI thường bị kéo về hai cực, Kubernetes dường như cũng phân cực y hệt
Tôi đã vận hành cluster đủ cỡ trong nhiều năm, nhưng chưa từng có lần nào nguyên nhân sự cố lại là do chính k8s
Có lần xảy ra một outage kiểu mất điện hoàn toàn kéo dài một giờ, và phe ghét k8s thì đổ hết cho cái "hệ thống k8s chết tiệt" đó
Nguyên nhân thật sự là một service trong hoàn cảnh nhất định đã mở hàng chục nghìn port gần như tức thì và gây ra tự DOS
Tôi không nghĩ k8s là tương lai của tất cả mọi thứ, cũng không nghĩ nó là rác; tôi cho rằng khi thật sự cần thì nó là một hệ thống tốt
Một là nó quá phức tạp để học, trong khi bài toán của tôi không cần đến nó và cách deploy cũ là đủ; hai là nó kém hiệu quả chi phí/năng lượng hơn bare metal
Thường thì hai điều này đi cùng nhau
Lập trường tương đối trung lập hoặc thờ ơ lại đang trở nên hiếm hơn, và chính trị Mỹ cũng là ví dụ dễ nghĩ tới
Tôi cũng không rành k8s, staff engineer mà nói về pod với cluster là mắt tôi bắt đầu lờ đờ, nhưng nó hợp với team tôi và chạy tốt ngoài thực tế
Với người chỉ có búa thì cái gì cũng trông như đinh, còn người cầm rìu thì lại thấy lạ vì sao ai cũng đòi bổ gỗ bằng búa
Thậm chí khi việc đó đúng là nên dùng rìu nhưng bạn lại bị người cầm búa cướp mất việc, thì việc ghét cái búa cũng càng dễ hiểu
Với k8s, best practice cho nhiều use case đã được định hình phần nào, còn bên LLM thì đến cả best practice là gì vẫn còn chưa rõ
Tôi rất đồng cảm với nhận định rằng VM bị buộc theo CPU/bộ nhớ nên ta đang trả tiền cho thời gian chứ không phải cho công việc
Vì thế tôi mua một server đấu giá giá rẻ của Hetzner rồi chạy trên đó orchestrator Firecracker tự host do chính tôi viết
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
Điều tôi muốn là mua phần cứng rồi tùy ý chia nhỏ thành VM, còn provisioning hay lifecycle thì khỏi phải bận tâm
VM nhàn rỗi sẽ snapshot trạng thái bộ nhớ xuống đĩa và trả lại toàn bộ RAM, nên phần cứng là của tôi, VM thì disposable, và khi không làm gì gần như không tốn chi phí
Đặc biệt, việc có memory-state snapshot hóa ra mạnh hơn tôi tưởng rất nhiều vì mọi thứ đều có thể resume
Tôi có thể snapshot trạng thái Chromium đã đăng nhập rồi khi cần thì lập tức dựng bản sao phiên làm việc; agent thì làm việc trong sandbox và cả docker compose cho môi trường preview cũng chạy ở đó
Khi không chạy gì, server gần như idle, và một cỗ máy 100 đô một tháng xử lý được tất cả chuyện này
Có viết kỹ hơn ở https://shellbox.dev/blog/race-to-the-bottom.html
Tài liệu đầy đủ và hữu ích, nhưng khá nhiều đoạn có mùi AI viết, nên sẽ tốt hơn nếu ngắn gọn hơn một chút
Dù vậy, phần "design decisions" đặc biệt hay và tôi cũng học được vài điều mới từ đó
Nếu chưa thì đáng để đăng lên Show HN
Đã có quá nhiều phần mềm chẳng ai dùng, nên tôi không hiểu vì sao người ta lại ám ảnh với chuyện sản xuất thêm nhiều code hơn
Chỉ cần nhìn App Store cũng đã thấy đầy phần mềm không ai đụng tới
Theo tôi, ứng dụng hiển nhiên hơn của LLM không phải là tạo ra thêm nhiều phần mềm, mà là tạo ra phần mềm tốt hơn
Tôi hy vọng trọng tâm sẽ bớt lệch khỏi code generation và chuyển sang hướng khác, vì có rất nhiều cách để LLM giúp viết code tốt hơn
Hình ảnh về một hệ thống tất định được chế tác cẩn thận, bảo trì và cập nhật vẫn sẽ còn đó, nhưng AI đã bắt đầu thay đổi cách người dùng tương tác với máy tính
Kết quả là có lẽ sẽ xuất hiện nhiều phần mềm gần như dùng một lần hơn
Hiện tại vẫn còn ở giai đoạn "AI có thể giúp kỹ sư viết phần mềm như thế nào", nhưng tôi nghĩ đang dần chuyển sang "kỹ sư phải làm gì để AI viết phần mềm tốt hơn"
Khi đó sẽ xuất hiện một lớp kỹ sư mới với góc nhìn hoàn toàn khác về việc phần mềm là gì và nên tạo ra tương tác máy tính như thế nào
Có lẽ sẽ có cực nhiều phần mềm tùy biến chưa bao giờ xuất hiện trên app store
Muốn gọi là Jevons paradox thì phải là tình huống chi phí sản xuất phần mềm giảm, nhưng mức tăng nhu cầu lại lấn át phần tiết kiệm đó đến mức tổng chi tiêu tăng lên
Khái niệm này chỉ đúng trong những thị trường mà lượng cầu phản ứng mạnh với thay đổi giá, tức là có độ co giãn cầu cao
Ngoài game ra, có lẽ sau này ta sẽ nhìn lại và thấy việc tạo một phần mềm đơn lẻ cho hàng triệu tới hàng tỷ người dùng là cách làm kỳ quặc đến mức nào
Giờ đây mọi người có thể tạo ra phần mềm làm đúng chính xác việc mình muốn, ít bị lôi kéo bởi ưu tiên lệch nhau hay mô hình doanh thu méo mó
Theo định nghĩa đó thì phần mềm ấy cũng có thể được xem là chất lượng cao hơn
Nhờ vậy cả hai phía đều dễ dự báo chi phí và doanh thu hơn, nhưng cốt lõi lại là tạo ra phần mềm càng phổ dụng càng tốt
Hệ quả là UX hay tính năng chỉ quan trọng với một số người dùng cứ liên tục bị cắt bỏ
Vibe coding và phát triển tăng tốc bằng LLM có thể đảo ngược điều đó
Giờ đây ai cũng có thể gánh nổi phần mềm tùy chỉnh theo nhu cầu và sở thích của riêng mình, và ta có thể hình dung một thế giới nơi thay vì 150 nghìn khách hàng Salesforce dùng cùng một CRM thì sẽ có 150 nghìn CRM tùy biến khác nhau
Dư địa mở rộng của phần mềm hiện giờ là rất lớn
Nếu không hiểu chu kỳ phình to của phần mềm, người ta sẽ cứ lặp lại cùng một sai lầm
Bắt đầu từ lean software, rồi tích dần các tính năng người dùng yêu cầu, sau đó thành một mớ bloated mess, rồi lại cần một bản viết lại nhỏ hơn, và quay lại lean software
Việc reboot thường либо thất bại, hoặc là làm trúng cái gì đó cốt lõi và tiến lên đủ xa để đe dọa kẻ đang thống trị
Cách nhìn hạ thấp DevOps như thể chỉ là thứ để tô CV hay là nguồn gốc của sự phức tạp quá mức nghe giống tư duy startup hơn
Ở công ty nhỏ có thể một người DevOps lo toàn bộ hạ tầng, nhưng đặc biệt trong tài chính thì những người thực sự cầm lái thường là các MD platform engineering
Họ chia kỹ sư phần mềm thành rất nhiều nhóm nhỏ và muốn mỗi team kiểm soát repo của mình, deployment của mình, mọi thứ của mình, đồng thời tin rằng microservices trao cho họ quyền đó
Tôi dám chắc phía DevOps ghét sự phức tạp
Chính họ là người bị gọi vào ban đêm và cuối tuần, và mọi chuyện luôn bắt đầu với giả định rằng "đó là vấn đề hạ tầng"
Log deploy đều đã vào hệ thống tổng hợp log cả rồi, vậy mà việc chính developer tự xem log để xử lý vấn đề deploy của mình lại hiếm, và rất nhanh là nó biến thành Incident
Có lẽ giờ cũng nên xem microservices là một trào lưu đã qua rồi
Tôi có thiện cảm với exe.dev, và rõ ràng vẫn có cơ hội cho thứ vừa làm mượt luồng phát triển với LLM vừa mang lại sự linh hoạt của một máy Linux có quyền root
Nhưng khi đọc câu "liên tục bị phản bội bởi các lớp trừu tượng nửa vời, nửa chín" thì nghịch lý là đó cũng chính là trải nghiệm tôi có với Tailscale
Họ nói sẽ làm networking dễ đi, nhưng sao pin lại tụt nhanh như vậy, sao lại thay đổi firewall rule theo cách xung đột với công cụ khác, và vì sao bug tracker lại im ắng đến mức cuối cùng tôi vẫn phải tự hiểu phần triển khai bên trong
Thế là tôi chỉ muốn nói "No thank you"
Bản thân dịch vụ đó trông thật sự rất hay
Tôi không định viết ACL cho router, mà muốn dựng một lớp mạng peer-to-peer, và đó là chỗ khiến tôi thấy tiếc
Tôi thì cứ dùng Hetzner
Mọi thứ các công ty cloud cung cấp đều quá đắt, còn Postgres HA và backup tôi tự vận hành thì suốt 10 năm không downtime mà chi phí chỉ khoảng một phần mười so với production RDS hay CloudSQL
Tôi tự autoscale instance bằng metric thu từ Grafana, và autoscaler dựa trên webhook cũng chạy cực kỳ đơn giản, chưa từng gây sự cố
Nên giờ tôi thật sự không hiểu vì sao phải dùng GCP hay AWS nữa
Dịch vụ đều HA và backup hằng ngày cũng rất ổn
Mục tiêu khi đó là tái hiện nguyên vẹn trải nghiệm dedicated server linh hoạt nhất nhưng với chi phí thấp, và UML đã làm được điều đó
Nhưng suốt thập niên 2010 tôi đã đoán sai hoàn toàn rằng đa số developer sẽ không vì một chút tiện lợi mà chấp nhận bị tính phí theo từng mảnh của cả stack
Tôi tò mò không biết các kỹ sư phần mềm tuổi 20 ngày nay còn biết cách dựng một nền tảng web app lưu lượng cao bằng server và router mua trên eBay hay không
Tôi cũng đã làm đúng kiểu đó vào năm ngoái để dựng một datastore hơn 50PiB, và thật sự muốn biết ở các dự án cỡ vừa đến lớn thì cách làm này được dùng nhiều đến đâu
Hetzner loại bỏ rất nhiều phiền toái vật lý trong khi gần như vẫn giữ nguyên lợi thế kinh tế, nên tôi khó hiểu vì sao họ chưa trở thành vua của thế giới hosting mà tính đến 2021 doanh thu mới ở mức 367 triệu euro
Cũng khó mà tin rằng kiến thức vận hành một bó dedicated server lại chuyên biệt đến mức người ta bỏ qua khoản tiết kiệm lớn như vậy
Tuy vậy, nếu kiếm được đúng nhân sự thì tự vận hành đúng là có thể rẻ hơn rất nhiều
Cron mỗi phút chạy docker pull để lấy image mới nhất, và chỉ khi có version mới thì mới docker up -d để thay thế
Phía trước đặt caddy để lo HTTPS, và nhiều năm nay mọi thứ chạy rất rẻ và ổn định
Trông giống một nhà cung cấp ở Anh với triết lý tương tự, tôi chưa dùng nhưng đã tạo tài khoản để cân nhắc cho VPS tiếp theo
Ngay từ đầu đã có thể gánh một server nhanh hơn 5 lần, nên nhiều lúc chẳng cần autoscaling
Các lựa chọn thay thế vốn đã có nhiều, và tôi là người làm ra https://shellbox.dev
Khác với exe, nó tính phí theo mức sử dụng thực tế, scale-to-zero được, và có thể bật VM ngay bằng SSH
Đây là Linux thông thường nên hỗ trợ cả VSCode remote lẫn Zed remote, và cũng cho phép nested virtualization
Nếu muốn đầu tư thì 5 triệu đô là tôi cũng thấy ổn
Không có port nào lộ ra ngoài, và mọi web frontend đều được bảo vệ bằng mật khẩu
Tôi không định công khai nó; đây là môi trường phát triển cách ly cá nhân chạy trên chiếc Raspberry Pi phía sau TV
Chi phí thực tế gần như bằng 0
Chúc dịch vụ của bạn thành công
Chẳng hạn vẫn chưa rõ hạ tầng nền thực tế nằm ở đâu, có những bảo đảm bảo mật nào, nên khó giao workload cho nó