- Chia sẻ kinh nghiệm của một nhà phát triển đã chuyển từ AWS sang máy chủ riêng và cắt giảm chi phí hạ tầng hàng tháng xuống còn 1/10, từ 1.400 USD/tháng xuống 120 USD/tháng, đồng thời có được hiệu năng máy chủ mạnh hơn
- Máy chủ bare metal do các nhà cung cấp như Hetzner cung cấp có giá khoảng 190 USD/tháng cho 80 lõi, rẻ hơn 7–18 lần so với các instance cấu hình tương đương trên AWS
- Lý do các kỹ sư cloud phản đối việc tự vận hành máy chủ là vì sự ổn định việc làm và sự phụ thuộc vào hạ tầng phức tạp, trong khi gánh nặng chi phí thực tế do người sử dụng lao động chịu
- Phần lớn doanh nghiệp nhỏ không cần các tính năng cấp doanh nghiệp như độ sẵn sàng cao, sao chép đa vùng hay tự động failover, và chỉ với một máy chủ đơn lẻ cũng có thể xử lý hàng triệu request mỗi ngày
- Việc quản trị máy chủ ổn định sau giai đoạn thiết lập ban đầu, và nhờ công cụ AI mà rào cản để vận hành máy chủ Linux hiện đang thấp nhất từ trước tới nay
Các trường hợp cắt giảm chi phí cloud
- Gần đây đã chuyển toàn bộ dự án ra khỏi cloud, đạt được giảm 10 lần chi phí AWS hàng tháng và tiết kiệm hàng nghìn USD
- Hóa đơn AWS hàng tháng giảm từ khoảng 1.400 USD xuống dưới 120 USD
- Có được hạ tầng máy chủ mạnh hơn với chi phí rẻ hơn
- Hiệu năng tăng gấp đôi và không còn bị khóa vào nhà cung cấp
- Khi tweet này lan truyền, có hai phát hiện: nhiều nhà phát triển quan tâm đến cách làm, và cũng có không ít người bày tỏ sự phản cảm mạnh mẽ và thái độ đối đầu với ý tưởng này
- Từ góc nhìn kinh doanh, đây là lợi ích quá rõ ràng: chi phí giảm 10 lần, hiệu năng tăng gấp 2, thoát phụ thuộc nhà cung cấp, nhưng vẫn vấp phải phản ứng dữ dội
Lợi ích gắn với những người ủng hộ cloud
- Phần lớn những người phản đối đều có trong hồ sơ các từ khóa như "devops", "cloud engineer", "serverless guy", "AWS certified"
- Họ không vận hành dự án của chính mình trên cloud và cũng không trực tiếp trả tiền cho chi phí cloud
- Họ thờ ơ với hóa đơn AWS của công ty và không thực sự cảm nhận được nỗi đau khi hàng nghìn USD bị lãng phí mỗi tháng
- Vì sao AWS lại tiện với họ
- Nó trông phức tạp về mặt kỹ thuật nên khiến họ có vẻ thông minh hơn trước các nhà phát triển khác
- Nó tạo ra hiệu ứng phụ thuộc và khóa chặt, khiến họ khó bị thay thế với tư cách nhân viên
- Việc dùng cloud đảm bảo mức lương cao, nên họ không có động lực đưa ra quyết định hiệu quả cho doanh nghiệp
- Ngược lại, hạ tầng doanh nghiệp càng phức tạp và khó hiểu thì công việc của họ càng an toàn
- Họ sẽ không nói cho bạn biết sự thật rằng máy chủ thực ra rất rẻ
Các lựa chọn thuê máy chủ giá rẻ
- Chuyển sang Hetzner (không liên kết, chỉ đơn giản là cung cấp máy chủ rẻ)
- Có thể thuê máy chủ bare metal 80 lõi với giá dưới 190 USD/tháng
- Các instance dòng C5-C6 trên AWS có cấu hình tương đương có giá 2.500–3.500 USD/tháng, tức đắt hơn 13–18 lần
- Ngay cả với reserved instances thì cũng khoảng 1.300 USD/tháng, vẫn đắt hơn 7 lần, lại còn cần trả trước 46.000 USD và cam kết 3 năm
- Các lựa chọn VPS cũng hấp dẫn
- Máy 48 vCPU giá 300 USD/tháng, không phí thiết lập hay hợp đồng dài hạn, đảm bảo độ linh hoạt hoàn toàn
- Máy 8 lõi, 32GB RAM giá 50 USD/tháng, nếu không phải xử lý hàng triệu request mỗi ngày thì có thể chạy đồng thời mọi dự án
Mua máy chủ và sử dụng trung tâm dữ liệu
- Về dài hạn thì mua máy chủ còn rẻ hơn
- Có thể mua máy chủ rack mount với 44 CPU, 256GB RAM, 2TB NVMe SSD với giá dưới 1.000 USD
- Rẻ hơn cả chi phí cloud theo tháng, đủ để chạy ứng dụng trong nhiều năm
- Lựa chọn thuê chỗ đặt rack tại trung tâm dữ liệu
- Có thể thuê cage trung tâm dữ liệu hoặc không gian rack dùng chung, nơi đã có điện, internet, làm mát và bảo mật
- Có thể tìm trung tâm dữ liệu theo khu vực qua các website như DatacenterMap
- Nhưng điều này quá phức tạp với nhà phát triển nhỏ lẻ
- Cần thuê kỹ sư, đàm phán giá và nhiều bước phiền phức khác
- Chủ yếu phục vụ doanh nghiệp vừa và lớn, không thực tế với các nhóm nhỏ
- Về bản chất cũng giống như thuê máy chủ đã được lắp sẵn từ những nơi như Hetzner, nhưng đỡ gánh nặng quản lý phần cứng hơn
Phản biện lại chỉ trích kiểu “vẫn là cloud thôi mà”
- Chỉ trích phổ biến nhất: "Cái đó vẫn là cloud thôi mà", "Bạn đâu có rời cloud, chỉ là đổi nhà cung cấp cloud"
- Đây là kiểu chỉ trích bỏ lỡ điểm cốt lõi
- Điều quan trọng là giá trị giữa việc tự quản lý máy chủ so với mặc định coi cloud là tất nhiên
- Nếu vận hành một máy Linux nhỏ để thay thế các dịch vụ managed đốt tiền như RDS thì bạn sẽ trả ít hơn 10–100 lần
- Phần lớn nhà phát triển sợ máy chủ, nhưng chỉ cần một chút khích lệ để thấy rằng họ có thể tự thiết lập máy chủ riêng với chi phí thấp
- Trong thế giới thực, gần như chẳng ai cần các dịch vụ managed đắt đỏ của cloud; vài máy Linux chạy phần mềm thông thường là đủ
- Tranh cãi về cách gọi làm mờ bản chất
- Dù là VPS, bare metal, on-premise hay colo thì tên gọi không quan trọng
- Dù sao máy chủ cũng phải đặt ở đâu đó; điều quan trọng là bạn giữ được nhiều tiền hơn trong túi hay chuyển nó cho cổ đông Amazon
- Những người đưa ra kiểu lập luận này về bản chất đóng vai gatekeeper
- "Làm vậy chưa đúng đâu, phải tự mua switch, tự dựng rack, tự bấm cáp Ethernet mới chuẩn"
- Đây là lối tranh luận độc hại và lười biếng, bám vào chi tiết bề mặt để né tránh điểm chính
Chi phí cloud vốn dĩ đắt đỏ
- Những nỗ lực gaslighting từ phe ủng hộ cloud
- "Bạn đang dùng cloud sai cách", "Đắt là vì bạn làm sai", "Phải biết cách dùng cloud"
- Họ chưa từng thực sự thử giải pháp thay thế, và không có kinh nghiệm thực tế trong việc quản lý máy chủ cho chính dự án của mình
- Tác giả thì quen thuộc với AWS và cũng từng học chứng chỉ AWS
- Kiểm tra xem hạ tầng có bị overprovision hay không
- Kiểm tra có đang trả tiền cho dịch vụ không dùng đến hay không
- Đã dành vô số thời gian để tối ưu chi phí AWS, thậm chí từng cắt hơn một nửa hóa đơn AWS trên 5.000 USD/tháng
- Đều biết về serverless computing, reserved instances và các thứ tương tự
- Reserved instances chỉ làm vấn đề tệ hơn: tạo vendor lock-in và trói bạn vào cam kết 3 năm
- Trong bối cảnh đang cân nhắc rời cloud, hợp đồng 3 năm là lựa chọn tệ nhất
- Kết luận sau mọi nỗ lực: cloud đơn giản là quá đắt
Nguyên nhân của phản ứng dữ dội
- Vì sao nhiều người lại quan tâm tới việc cắt giảm chi phí đến vậy?
- Có hai kết luận chính
- Miếng cơm manh áo bị đụng chạm: nếu đủ nhiều người bị thuyết phục bởi quan điểm này thì họ có thể mất việc
- Tranh luận phi lý do nỗi sợ: 10 năm qua xây dựng trên cloud là xu hướng, tạo ra hàng triệu vị trí "devops" và "cloud engineers"; nếu xu hướng mới là rời cloud thì sự nghiệp của nhiều chuyên gia cloud có thể chấm dứt
- Nhiều nhà phát triển âm thầm biết rằng cloud không tốt như những lời hứa ban đầu
- Họ nhìn hóa đơn AWS của công ty cao gấp 10 lần mức hợp lý nhưng vẫn bỏ qua và nói "không sao đâu"
- Họ không muốn mạo hiểm làm sếp phật ý hoặc gánh trách nhiệm
- Họ sợ cái giá chính trị khi bất đồng với người có tiếng nói lớn nhất trong nhóm
- AWS có một lượng tín đồ mang màu sắc sùng bái rất mạnh
- Họ được đào tạo bằng chứng chỉ để ghi nhớ các trang bán hàng và mô tả sản phẩm thực chất là tài liệu marketing
- Họ có các evangelists rao giảng giáo điều thay vì chủ nghĩa thực dụng
- Họ gieo nỗi sợ về thế giới bên ngoài (máy chủ thì nguy hiểm! không scale được!)
- Họ biến "cloud engineer" thành một bản sắc, khiến việc bước vào thì dễ mà thoát ra thì khó
- Vì sinh kế bị gắn chặt vào đó, những người theo AWS mắc kẹt trong giáo điều và lặp lại các lập luận phi lý
- Họ lặp lại từng luận điểm trên trang landing page bán hàng của AWS mà không nghĩ xem có thực sự cần hay không
- Vì đây là tranh cãi về hệ thống niềm tin nên con người trở nên thiếu lý trí
Lịch sử của cloud
- Trước đây ai cũng tự vận hành máy chủ
- Trên VPS, dịch vụ hosting, bare metal trong trung tâm dữ liệu, phòng tối trong công ty, hoặc ngay tại nhà
- Ai cũng quen và thoải mái với việc SSH vào máy
- Đầu những năm 2010, chiến dịch marketing và psyops cho cloud bắt đầu
- Đây là động thái có chủ ý nhằm bán công nghệ doanh nghiệp cho các startup giai đoạn đầu
- Mục tiêu là khóa họ vào hệ sinh thái càng sớm càng tốt để khi gọi vốn thì có thể khai thác
- Chiến lược của AWS
- Bắt đầu cung cấp tín dụng riêng cho startup
- Đi vòng quanh các accelerator để đưa mọi startup lên hệ thống
- Mánh rất đơn giản: làm cho việc xây hạ tầng ban đầu cực rẻ (thậm chí miễn phí!), rồi khi startup tăng trưởng thì biến mọi thứ thành cực kỳ đắt đỏ, tận hưởng việc họ đã bị khóa chặt và khó thoát khỏi hệ sinh thái
- IBM cloud cũng có chiến lược tương tự (một sự kiện năm 2014)
- Khi đó mọi thứ đang chạy trên Heroku và hoạt động tốt
- Có cảm giác như: "Toàn bộ đống cloud này là gì và dùng thế nào?"
- Giống như họ đang cố bán thứ không được thiết kế cho mình
- Trong nhiều năm qua, các công ty này đã đổ hàng triệu USD vào các chiến dịch quảng bá cloud để lôi kéo startup giai đoạn đầu chấp nhận công nghệ doanh nghiệp
- Môi trường lãi suất bằng 0 trong 10 năm qua cũng góp phần tạo ra hiện trạng ngày nay
- Hiện đã có một phong trào phản văn hóa
- Chủ yếu do @dhh và cộng đồng Rails dẫn dắt
- Cách tiếp cận này về cơ bản mới mẻ, đúng đắn và phù hợp với thực tế của phần lớn doanh nghiệp phần mềm trên thế giới
Phần lớn doanh nghiệp không cần cloud
- Một số người có nhận thức hoàn toàn xa rời việc doanh nghiệp phần mềm thực tế trông như thế nào
- Họ suy nghĩ từ góc nhìn Fortune 500 và tin rằng enterprise là tiêu chuẩn mặc định
- Họ cho rằng doanh nghiệp trung bình cần độ sẵn sàng cao, sao chép đa vùng, tự động failover, cụm Kubernetes phân tán cùng mọi tính năng khác của cloud
- Nhưng thực tế chỉ có số rất ít doanh nghiệp phần mềm cần những thứ đó
- Phần lớn doanh nghiệp sẽ luôn nhỏ theo quy luật lũy thừa
- Ở Mỹ, doanh nghiệp nhỏ chiếm 99,9% tổng số doanh nghiệp
- Ở Liên minh châu Âu, SME (dưới 250 nhân viên) chiếm 99% tổng số doanh nghiệp
- Phần lớn nhà phát triển đánh giá quá cao nhu cầu scale
- Ngưỡng của họ cho "lưu lượng cao" quá thấp
- Mốc tham chiếu: hiện tại thiết lập 2 máy chủ đang xử lý hàng triệu request mỗi ngày cho hàng triệu khách truy cập mỗi tháng
- Các indie maker như @levelsio xử lý mọi thứ chỉ bằng một máy chủ duy nhất
- Đa số nhà phát triển chưa từng chạy dự án của chính mình với người dùng thật và traffic production thật trên một máy chủ đơn lẻ
- Các yêu cầu kỹ thuật cũng bị đánh giá quá cao
- Chỉ cực ít doanh nghiệp phần mềm cần các tính năng đó, và thường họ có đủ lý do kỹ thuật để đưa ra quyết định đó
- Trường hợp như Netflix: phải transcoding và streaming lượng video khổng lồ cho khách hàng toàn cầu nên cần hệ thống phân tán, CDN và edge computing
- Nhưng nếu chỉ là một ứng dụng nhỏ với một nghìn người dùng trao đổi vài đối tượng JSON thì hoàn toàn không cần những thứ đó
- Nhiều nhà phát triển có một ảo tưởng rằng dự án của mình giống Netflix
- Đó là kiểu suy nghĩ đầy hy vọng, dễ hiểu nhưng dẫn tới quyết định kỹ thuật sai lầm
- Họ tin rằng phải phân tán máy chủ toàn cầu vì người dùng sẽ nhận ra sự chênh lệch vài mili giây khi chạm vào một nút
Máy chủ sẽ ổn thôi
- Nhiều người có suy nghĩ mang màu sắc ma thuật về cách trung tâm dữ liệu hoạt động
- Họ nghĩ máy chủ trong trung tâm dữ liệu rất mong manh, biến động và có thể biến mất vào không trung
- Thậm chí có người nghĩ sét đánh có thể làm sập cả trung tâm dữ liệu
- Trung tâm dữ liệu hiện đại đã tính đến mọi vấn đề và có rất nhiều lớp bảo vệ
- Không chỉ với những thứ bình thường như sét đánh mà gần như với mọi thứ có thể đe dọa uptime
- Nguồn điện dự phòng, hệ thống làm mát dự phòng, kết nối internet dự phòng, hệ thống chữa cháy dự phòng, hệ thống an ninh dự phòng cùng rất nhiều bảo mật vật lý
- Mọi thứ trong trung tâm dữ liệu đều được thiết kế với khả năng phục hồi và dự phòng (ít nhất là N+1, đôi khi là 2N) để đảm bảo uptime
- Đây chủ yếu là ý kiến dựa trên nỗi sợ, là kết quả của chiến dịch marketing và psyops cloud thành công
- AWS lưu máy ở đâu? Trong một nơi kỳ diệu dưới cầu vồng sao?
- Tại sao chỉ máy của AWS lại được bảo vệ thần kỳ khỏi những vấn đề mà các trung tâm dữ liệu khác cũng có?
- Tất nhiên thảm họa vẫn có thể xảy ra (vụ cháy OVH năm 2021), nên cần backup để phục hồi
- Nhưng theo kinh nghiệm khoảng 15 năm vận hành máy chủ, chuyện này hiếm đến mức gần như chưa từng gặp downtime kéo dài quá vài phút
Quản trị máy chủ không phải công việc toàn thời gian
- Những ai đã quản lý máy chủ đủ lâu đều biết phần lớn thời gian nằm ở khâu thiết lập ban đầu, còn sau đó máy chủ tương đối ổn định
- Hỏng hóc phần cứng khá hiếm, và khi máy chủ đã chạy ổn thì thường có thể hoạt động hoàn hảo nhiều năm mà không cần can thiệp lớn
- Tự quản lý máy chủ không phải công việc toàn thời gian
- Không cần thuê đội devops 5 người
- Cũng không cần thuê riêng người phụ trách máy chủ: bạn hoàn toàn có thể tự làm và nó không hề khó đến thế
- Claude và ChatGPT có hiểu biết tốt về hệ thống Linux và cách quản trị, nên có thể nhờ trợ giúp
- Sau khi đăng tweet, có người cho rằng đây là lần đầu tác giả vận hành máy chủ và rằng tác giả quá lạc quan về ý nghĩa thực sự của việc đó
- Nhưng tác giả đã có kinh nghiệm quản lý máy chủ từ năm 2006
- Bắt đầu bằng việc sửa script PHP và tải chúng lên server FTP
- Học cách cài WordPress, chỉnh sửa template WP rồi từ đó mọi thứ tiếp tục phát triển
- Đó là một trải nghiệm quý giá và dạy những điều nền tảng
- Học Linux là gì và cách di chuyển trong đó
- Tới năm 2007 còn từng yêu cầu Canonical gửi đĩa CD-ROM Ubuntu qua đường bưu điện để cài lên phân vùng trên máy tính của bố mẹ và học Linux
- Những trải nghiệm đầu đời đó đã dạy các nền tảng của phát triển web, và mọi thứ khác đều được xây trên đó
Tầm quan trọng của việc học Linux
- Thế hệ nhà phát triển mới (Gen Z, Gen Alpha) bị tách rời hoàn toàn khỏi phần cứng chạy phần mềm
- Họ thiếu kiểu trải nghiệm nền tảng này
- Họ sinh ra trong thời đại mà một người ngẫu nhiên trên YouTube quảng bá một vendor cụ thể và dạy chạy một lệnh nào đó như thể mọi vấn đề hạ tầng đều được giải quyết bằng phép màu
- Vì vậy, việc họ có những giả định mang tính ma thuật về máy chủ là gì và nó hoạt động ra sao cũng là điều dễ hiểu
- Họ tuyên bố có thể làm việc bằng "serverless" nhưng không nhận ra rằng họ vẫn đang chạy code trên nhiều chiếc máy khác nhau
- Tất nhiên vẫn có nhiều người học thêm về Linux và máy chủ, nhưng một học viên bootcamp trung bình ngày nay thiếu trải nghiệm Linux thực hành mà những người "FTP hacker" 20 năm trước từng có
- Đây không phải phán xét đạo đức, không nói tốt hay xấu — đó đơn giản là trạng thái hiện tại của phát triển web
- Kết quả là những công ty như Vercel đang kiếm hàng triệu USD bằng cách khai thác thế hệ nhà phát triển mới không thực sự biết mình đang làm gì và chưa từng vận hành máy chủ trong đời
- Sự thiếu hiểu biết phải trả giá hai lần: cái giá của chính sự thiếu hiểu biết và cái giá bạn trả cho những người lợi dụng nó
- Không biết mọi thứ hoạt động thế nào thì thực sự sẽ tốn tiền
Bây giờ là thời điểm tốt nhất để học về máy chủ
- Nếu bạn chưa từng tự quản lý máy chủ và thấy sợ mọi thứ mang mùi backend, điều đó cũng không sao
- Thực ra chưa bao giờ có thời điểm nào tốt hơn để giỏi về máy chủ như hiện nay
- Claude và ChatGPT đều biết rất rõ về Linux, có thể hướng dẫn từng bước theo cách chưa từng có trong lịch sử công nghệ
- Không chỉ giúp hiểu cách thiết lập và cách nó hoạt động, mà khi cần thay đổi bạn cũng có thể hỏi và làm theo từng bước mà không phải thuê ai
- Nó không đáng sợ đến vậy, và cũng không phải làm quá thường xuyên
- Trong thời đại AI nơi việc sinh mã đã trở thành tiêu chuẩn và code có thể trở thành hàng hóa, việc biết cách triển khai code đó lên máy chủ production giá rẻ và thực sự biến nó thành thứ hữu ích cho người dùng cuối có thể trở thành yếu tố khác biệt cốt lõi của một nhà phát triển
- Đúng là vẫn phải lo những thứ như bảo mật
- Hãy bỏ ngoài tai lập luận cho rằng tự vận hành máy chủ kém an toàn hơn vận hành máy chủ trên AWS như thể instance EC2 được bảo vệ thần kỳ khỏi hacker,
- Thực tế là cấu hình cho đúng không khó đến vậy, chỉ cần tham khảo hướng dẫn và script thiết lập
- Nhiều nhà phát triển giàu kinh nghiệm hơn bạn vẫn đang làm production tệ hơn rất nhiều so với bạn khi có AI hỗ trợ
- Chỉ cần hỏi ChatGPT cách harden máy chủ Linux và làm theo các best practices bảo mật (không dùng password authentication, chỉ dùng SSH key mạnh) là đã xong 90%
- Có thể dùng Cloudflare như một lớp bảo vệ bổ sung
- Sau khi khóa chặt máy Linux, cho mọi thứ chạy phía sau Cloudflare
- Nếu proxy IP máy chủ trong DNS để không lộ địa chỉ thật thì quá ổn
- Về cơ bản sẽ có chống DDoS, edge caching và DNS hàng đầu gần như miễn phí
24 bình luận
Nếu nghĩ đến thời gian và công sức cần bỏ ra để tự xây dựng hạ tầng cần thiết tại chỗ, thì dịch vụ đám mây cũng không đến mức đắt đỏ như vậy.
Và dịch vụ đám mây được dùng vì tính sẵn sàng cao, chứ không phải vì chi phí.
Tôi thấy nó giống kiểu của IKEA hay Daiso.
Chắc chắn cũng có những dịch vụ đám mây rất đáng tiền và hợp lý.
Nhưng rồi khi dùng những cái đó, bạn lại bắt đầu dùng kèm những thứ trông đắt hơn một chút.
(Ví dụ đại khái thôi) dùng Lambda thì giờ lại dùng cả API Gateway, mà cái này thì hơi đắt và bất tiện -_-^
Đại loại là như vậy.
Mà điều tôi cực kỳ đồng cảm là:
Lý do AWS tiện cho những người này
Là vì nó trông phức tạp về mặt kỹ thuật nên khiến họ có vẻ thông minh trước mặt các lập trình viên khác
Chính là câu đó.
Thật lòng mà nói, vì các dịch vụ AWS đã có từ lâu và tiến hóa dần theo thời gian nên có không ít tính năng mà họ thậm chí còn chưa thể deprecate, và việc hiểu rõ những thứ đó từng trông rất ngầu nên tôi cũng đã lấy chứng chỉ SA rồi haha.. đồng cảm mạnh ~~
Cloud, on-premise và IDC đều có ưu và nhược điểm riêng, nên rốt cuộc điều cốt lõi là chọn phương án phù hợp với mục đích sử dụng và quy mô.
Tiền đề lớn nhất là "sự cố phần cứng hầu như không xảy ra" nhưng...
Theo trải nghiệm của tôi, hồi công ty thuê rack ở IDC để vận hành server thì cứ khoảng 3 ngày lại có một ổ đĩa chết,
nên tôi vẫn nhớ cảnh phải đi thay ổ đĩa rồi khôi phục RAID...
Nếu có thể thì cứ dùng cloud thôi.
Khi phần cứng hỏng mà chỉ cần "tách" một cái là dựng lại được thì giá trị của nó lớn đến mức nào chứ.....
Ổ đĩa hỏng cứ khoảng 3 ngày một lần thì hơi bất thường đấy...
Có vẻ đây không phải là trường hợp phổ biến.
Đây là câu chuyện từ hơn 10 năm trước, và có lẽ là Seagate.. thì phải.
Backblaze đã công bố năm ngoái có 4.372 ổ bị hỏng, nên ở quy mô đó thì đúng là cứ khoảng 2 giờ lại có một ổ đĩa hỏng...
Đây là tần suất có thể xảy ra ở quy mô cực lớn.
Ừm, tôi đã làm việc khá lâu trong một môi trường có phòng máy tính quy mô 100 rack 42U, được cấu thành từ HPC, HCI, hệ thống tệp phân tán xây dựng bằng Hadoop thời kỳ đầu và đủ loại storage, nhưng tôi chưa từng thấy chuyện cứ 3 ngày lại hỏng một ổ đĩa lần nào.
Ý kiến Hacker News
Tôi đã tự vận hành máy chủ suốt nhiều năm, giữ mọi thứ đơn giản và tiết kiệm được rất nhiều thời gian lẫn chi phí
Tôi tránh AWS hay Azure vì cấu hình phức tạp và UI cũng không tốt lắm
Điều quan trọng là phải quản lý để có thể tái tạo máy chủ chỉ bằng các tệp cấu hình bất cứ lúc nào. Vì vậy các công cụ như Ansible là bắt buộc
Nếu thật sự phải dùng cloud thì tôi khuyên dùng DigitalOcean. Nó đơn giản, trực quan và tốt cho sức khỏe tinh thần
Tôi chỉ dùng DO cho mục đích phục hồi thảm họa cấp 3, và tự động cấu hình cluster bằng Terraform và Ansible
Phần lớn cộng đồng lập trình viên có xu hướng chạy theo trào lưu, nhưng ngay trong bầu không khí đó tôi vẫn triển khai monolith Clojure chạy trên JVM trên cluster máy chủ vật lý của mình và tạo ra doanh thu ổn định
thiết lập ulimit, vấn đề hiệu năng của SYN cookies, cập nhật bảo mật, ứng phó tấn công zero-day, gửi email (làm ấm IP, quản lý danh sách spam), tuân thủ GDPR, v.v.
Tất cả những điều đó đều là trách nhiệm của tôi, và những người dùng cloud không đơn giản chỉ là ‘bị lừa’
Tôi ghét tư duy trắng đen. Phần lớn startup sẽ tiết kiệm được rất nhiều tiền nếu chuyển từ EC2 sang những nơi như Hetzner, Linode, DigitalOcean
Nhưng cloud cũng có rất nhiều ưu điểm — các tính năng như backup, DB được quản lý, multi-AZ có thể dùng chỉ với vài cú nhấp chuột
Không có chi phí đầu tư phần cứng ban đầu, và nếu tải đỉnh cao thì đôi khi còn rẻ hơn
Tuy nhiên, vì thời gian kỹ sư rất có giá trị nên ở giai đoạn tăng trưởng nhanh, cloud có thể là lựa chọn hợp lý
Cuối cùng, cloud không đắt vì bản thân nó đắt mà vì bạn đang dùng những tính năng không cần thiết nên mới đắt
Cũng có nhiều trường hợp chiến lược multi-cloud đã ngăn được thảm họa
VPS hay máy chủ dedicated cũng gần như không có chi phí ban đầu, và nếu tải đỉnh không quá cực đoan thì cloud cũng không nhất thiết rẻ hơn
DB được quản lý thì tiện nhưng có rất nhiều nâng cấp bắt buộc, và nếu không ở quy mô lớn thì tôi cho rằng tự quản lý còn tốt hơn
Trước đây việc mở rộng phần cứng rất khó, nhưng giờ chỉ một máy chủ đơn lẻ cũng có thể đạt hiệu năng tương đương cả một rack ngày xưa
Các dự án quy mô vừa giờ đã có thể tự giải quyết những vấn đề mà trước đây cloud từng giải quyết
Tuy nhiên, để nhận hỗ trợ từ nhân sự bên ngoài thì cloud dễ hơn rất nhiều, còn self-hosting thì khó tìm người hỗ trợ
Cá nhân tôi thích self-hosting hơn, nhưng với những ai không muốn trực tiếp đụng vào hạ tầng thì cloud là lựa chọn tốt hơn
Trước đây tôi phụ trách IT ở một startup quỹ đầu cơ
Chúng tôi chạy chương trình phân tích C++ trên máy chủ dual Xeon (512GB RAM), nhưng sau khi sếp nghe ai đó hỏi trong bữa trưa rằng “sao không dùng AWS” thì bắt đầu thấy bất an
Tôi đã chứng kiến thực tế rằng ‘tuân thủ buzzword’ còn được coi trọng hơn hiệu quả
Nhiều CTO vì bầu không khí đó mà tiêu những khoản ngân sách lớn không cần thiết, và trong một thế giới như vậy, kiến trúc hiệu quả lại trở thành điểm yếu về mặt marketing
Cách nói “tiết kiệm 10 lần” là sai về mặt logic. 10 lần nghĩa là nhiều hơn gấp 10
So với chi phí máy chủ thì chi phí lao động bảo trì còn lớn hơn
Dù vận hành 10 EC2 instance thì vẫn có thể vá tự động bằng Systems Manager, nên không cần tự xây dựng hệ thống tự động hóa
Tranh luận về cloud không phải chuyện trắng đen
Quy mô nhỏ thì Hetzner hay AWS đều gần giống nhau, còn với doanh nghiệp lớn thì mấu chốt là họ có thể tự xây tooling hay không
Phân khúc doanh nghiệp vừa và nhỏ (SME) mới là vùng mơ hồ nhất. Nếu cần hệ thống tách biệt hoàn toàn theo từng khách hàng thì AWS có lợi hơn, còn nếu tải ổn định 24/7 thì máy chủ tự vận hành sẽ tốt hơn
Nếu chỉ dùng cloud như nơi host VM thì sẽ bị thiệt. Có rất nhiều trường hợp không dùng tính năng cloud nhưng vẫn trả tiền cloud
Máy chủ tự vận hành phải trả tiền cho công suất tối đa suốt cả tháng, còn cloud chỉ trả tiền cho vài ngày thực sự cần
Cloud rất hữu ích để xây MVP và kiểm chứng thị trường
Có thể thử nghiệm rất nhanh bằng startup credit và free tier, rồi nếu sau này chi phí trở thành vấn đề thì chuyển đi là được
Tuy nhiên, ngay từ đầu phải thiết kế theo kiến trúc độc lập với máy chủ, và việc dành thời gian cho migration không hề dễ
Đội của chúng tôi dùng Google Cloud, nhưng mức chi quá thấp nên nhân viên sales còn không hài lòng
Khả năng có thể chuyển giữa các cloud cũng tạo ra sức mạnh đàm phán
Ngoài ra, cloud giúp đáp ứng SLA hay các quy định bảo vệ dữ liệu dễ hơn nên có lợi cho việc xây dựng niềm tin với khách hàng doanh nghiệp
Tôi tò mò vì sao AWS lại bùng nổ mạnh đến vậy trong giai đoạn đầu
Đầu những năm 2010, thuê rack và dựng máy chủ vừa đắt vừa chậm, và cấu hình đa vùng (multi-region) gần như bất khả thi
AWS đã giải quyết những vấn đề đó, nhưng giờ tình hình đã khác
Cũng từng có giai thoại Squarespace tự mang nhiên liệu đến cứu máy chủ trong bão Sandy
Ở Hetzner, sau khi đặt máy chủ chỉ khoảng 10 phút là có thể cài Ubuntu và áp Ansible xong
Phí cố định, băng thông không giới hạn, hiệu năng có thể dự đoán — sức hút nằm ở sự đơn giản không có các tầng trừu tượng thừa thãi
EC2 đã xóa bỏ sự bất tiện đó, và Lambda còn tiến xa hơn nữa. Bây giờ thuê bare metal đã rẻ hơn rất nhiều
Chính sách free credit của AWS ngày trước thực chất là chiến lược lock-in
Tự đặt máy chủ vào data center không hề khó như người ta nghĩ
Tôi cần CPU xung nhịp cao cho máy chủ game, nhưng rất khó tìm trên cloud nên đã tự xây dựng
Tôi vận hành với chi phí khoảng £15/tháng gồm cả phí lắp đặt, và nó chạy tốt suốt nhiều năm. Kết quả là tiết kiệm được rất nhiều chi phí
Chúng tôi đặt thiết bị ở một data center tại Seattle và quản lý từ xa bằng KVM dùng modem
Vài năm trước chúng tôi đã chuyển sang Hetzner, và nhờ mức tiết kiệm đó có lẽ sẽ không quay lại cloud nữa
Ngoại lệ là Cloudflare Workers, chất lượng tốt và hạn mức miễn phí rất rộng rãi
Nhờ AI, việc viết script tự động hóa, triển khai và backup đã dễ hơn rất nhiều nên quản lý bây giờ đơn giản hơn trước
Nhân tiện, Claude Code của Anthropic hiện đang cung cấp $250 credit miễn phí cho người dùng Pro/Max đến ngày 18 tháng 11
Có thể xem thông báo liên quan trong tweet này
Chỉ cần từng trải qua một lần khôi phục từ bản sao lưu thôi thì chắc sẽ cảm nhận được giá trị của nó chứ? On-premise đau đầu nhất vẫn là khôi phục từ bản sao lưu.
Ừm... tôi hoàn toàn đồng ý với các ý như 'chi phí cloud đắt hơn mức cần thiết' và 'trong đa số trường hợp không cần đến các tính năng của các cloud lớn', nhưng giọng điệu của bài viết khiến người ta khó đọc vì nghe như đang khẳng định rằng mọi dịch vụ cloud đều là lừa đảo. Nó nghe giống như nói rằng 'mọi sản phẩm bảo hiểm đều là lừa đảo'.
Cloud là thứ người ta dùng khi không muốn tự quản lý server hoặc khi nhu cầu khó dự đoán và cần mở rộng nhanh. Ngoài những trường hợp đó thì tôi không rõ nó còn có ý nghĩa gì.
Tôi đồng ý với tất cả, nhưng thật tiếc là không có phần bàn về góc độ bảo mật khi tự vận hành máy chủ trong nhiều năm.
Tôi cũng muốn bỏ một phiếu cho ý kiến này.
Đúng vậy.
Tôi hoàn toàn đồng ý 100% rằng cloud là đắt.
Nhưng nếu nghĩ đến việc ngay lúc này phải tự cấu hình Kubernetes trên bare metal để vận hành hơn 200 container,
trong tình huống chỉ có 1 lập trình viên backend và không có devops, nếu xem đây là một lựa chọn giúp giảm gánh nặng quản lý, vận hành server với chi phí chỉ bằng một nửa của một nửa tiền lương một người, thì thực ra cũng không phải là lựa chọn tệ.
Nếu có nhân sự chỉ chuyên quản lý hạ tầng server, thì rời bỏ cloud chắc chắn cũng có thể là một lựa chọn tốt.
Cá nhân tôi thử xây dựng dịch vụ theo hướng loại bỏ cloud tối đa thì đúng là phát điên lên được.
Tôi cần một kho lưu trữ container image, nhưng khi bắt tay vào dựng thì storage cục bộ lại thành gánh nặng, vì tiện cho backup nên phải tìm giải pháp tương thích s3, rồi để chặn truy cập từ bên ngoài lại phải dựng thêm dịch vụ VPN, chưa kể reverse proxy, quản lý chứng chỉ HTTPS, và đủ kiểu thiết lập cho bảo mật CI/CD... tự dựng hết...
Nếu chỉ dùng vài dịch vụ đơn giản trên cloud thì dĩ nhiên bare metal rẻ hơn và dùng như vậy là hợp lý. Nhưng nếu cần tích hợp với các dịch vụ khác và muốn giảm bớt đủ thứ gánh nặng, thì dù chi phí server trước mắt có đắt hơn, việc không phải tự tay dựng từng dịch vụ như thế có thể khiến phần chi phí cài đặt/vận hành được cắt giảm và cuối cùng lại có lợi.
Có rất nhiều mã nguồn mở cho kho lưu trữ hình ảnh.
Đúng là có nhiều. Ý tôi là gánh nặng phải tự vận hành. Tôi cũng dùng Nexus hoặc Harbor.
Theo trải nghiệm cá nhân của tôi thì không có gánh nặng hay vấn đề gì cả.
Tiêu chuẩn về việc thế nào là gánh nặng có thể khác nhau ở mỗi người, nên cũng có thể hiểu là bạn nghĩ như vậy.
Bạn đang phát triển dịch vụ nào mà cần một kho lưu trữ image container?
Lý do là dù phát triển dịch vụ nào đi nữa, tôi vẫn thích triển khai bằng container. Tôi cũng ưu tiên triển khai theo cách hạn chế tối đa việc kết nối trực tiếp qua SSH. Nếu chỉ nghĩ đến chi phí thì... có lẽ cũng sẽ có những cách cho phép triển khai trực tiếp mà không cần registry, nhưng đây chỉ là ví dụ tôi nghĩ ra, và tôi muốn tập trung vào những điểm bất tiện có thể phát sinh như dịch vụ email chẳng hạn.