Kubernetes sẽ không biến mất chỉ sau một đêm. Với một hệ sinh thái khổng lồ và sự hỗ trợ của CNCF, nó vẫn ăn sâu vào nhiều tổ chức. Nhưng những vết nứt đang xuất hiện, và những tiếng thì thầm bất mãn đã lớn hơn.

Sau khi nói chuyện với các anh em kỹ thuật và phân tích các xu hướng hạ tầng gần đây, tôi đã xác định được lý do tại sao sự thay đổi này đang diễn ra và những lựa chọn thay thế nào đang ngày càng được ưa chuộng. Bức tranh hiện ra thậm chí còn làm tôi ngạc nhiên.

Điểm đột phá: Tại sao các công ty đang suy nghĩ lại về Kubernetes

Sự phức tạp không bao giờ mang lại lợi ích

Lời hứa thật quyến rũ: một cách thống nhất để triển khai, mở rộng và quản lý các ứng dụng container hóa. Thực tế? Một đường cong học tập dốc đến mức gần như thẳng đứng.

“Chúng tôi đã dành nhiều giờ kỹ thuật hơn để duy trì các cụm Kubernetes của mình hơn là xây dựng các tính năng mới,” một kỹ sư nền tảng cấp cao tại một startup kỳ lân đã từ bỏ triển khai K8s của họ gần đây thú nhận. “Đến một lúc nào đó, bạn phải tự hỏi liệu chi phí vận hành có đáng giá hay không.”

Tâm lý này vang vọng khắp các công ty ở mọi quy mô. Khối lượng nhận thức cần thiết để hiểu về pods, services, ingress controllers và bộ sưu tập các file YAML dường như vô tận tạo ra một rào cản mà nhiều đội không bao giờ vượt qua hoàn toàn.

Một giám đốc kỹ thuật tại một công ty Fortune 500 (người yêu cầu giấu tên) đã nói thẳng thừng: “Chúng tôi đã tính toán rằng 38% thời gian của đội DevOps của chúng tôi dành cho việc khắc phục sự cố Kubernetes thay vì cải thiện các pipeline triển khai của chúng tôi. Đó là một tỷ lệ không bền vững.”

Trung tâm chi phí ẩn

Việc quảng bá Kubernetes thường tập trung vào việc tiết kiệm chi phí thông qua tối ưu hóa việc sử dụng tài nguyên. Thực tế phức tạp hơn.

Giữa tài năng DevOps chuyên biệt (các kỹ sư được chứng nhận K8s đòi mức lương cao cấp), các cụm được cấp phát quá mức để xử lý các đợt tăng đột biến không mong muốn, và các tài nguyên đám mây cần thiết để chạy chính control plane, tổng chi phí sở hữu (TCO) của Kubernetes thường vượt quá dự kiến ban đầu.

“Chúng tôi nghĩ rằng mình đang thông minh khi hợp nhất các microservices của mình vào một dịch vụ Kubernetes được quản lý,” một tech lead tại một công ty SaaS cỡ trung chia sẻ. “Sáu tháng sau, hóa đơn đám mây của chúng tôi đã tăng 25%, chứ không hề giảm. Và đó còn chưa kể đến số lượng nhân sự bổ sung mà chúng tôi cần.”

Sự không phù hợp về mức độ trưởng thành trong vận hành

Có lẽ yếu tố bị bỏ qua nhiều nhất là Kubernetes yêu cầu một mức độ trưởng thành trong vận hành và kiến trúc microservice mà nhiều tổ chức đơn giản là không có.

“Chúng tôi đã ‘đặt cược tất tay’ vào Kubernetes trước khi kiến trúc của chúng tôi sẵn sàng,” một CTO mà công ty của ông gần đây đã thu hẹp quy mô K8s thừa nhận. “Chúng tôi đang chạy các monolith trong container và đối phó với tất cả sự phức tạp của Kubernetes mà không thực sự tận dụng được lợi ích của nó. Đó là kịch bản tệ nhất của cả hai thế giới.”

5 Lựa chọn thay thế đang ngày càng được ưa chuộng

Vậy các công ty đang chuyển sang đâu? Dưới đây là năm lựa chọn thay thế liên tục được nhắc đến trong các cuộc trò chuyện của tôi với các lãnh đạo công nghệ đã rời bỏ Kubernetes:

1. AWS App Runner + ECS: Đơn giản hơn Kiểm soát

Các giải pháp container của Amazon đã định vị mình là lựa chọn “đủ để điều phối” (just enough orchestration). ECS (Elastic Container Service) đã tồn tại lâu hơn cả Kubernetes, trong khi App Runner còn tiến xa hơn nữa trong sự đơn giản bằng cách trừu tượng hóa gần như tất cả các vấn đề quản lý container.

Điều thú vị là cách các công ty đang kết hợp các dịch vụ này. Một số lãnh đạo công nghệ đã mô tả việc sử dụng App Runner cho các ứng dụng đơn giản hơn, stateless, trong khi vẫn giữ ECS cho các khối lượng công việc cần tùy chỉnh nhiều hơn.

“Chúng tôi đã giảm chi phí quản lý hạ tầng của mình 60% kể từ khi chuyển từ EKS sang kết hợp App Runner và ECS,” Phó Giám đốc Kỹ thuật tại một công ty công nghệ tài chính báo cáo. “Các nhà phát triển của chúng tôi có thể tự triển khai lại mà không cần phải hiểu những phức tạp của mạng Kubernetes.”

Sự đánh đổi là ít kiểm soát chi tiết hơn, nhưng nhiều công ty đang nhận thấy đó là một cái giá đáng trả cho sự đơn giản trong vận hành.

2. Nomad: Công cụ điều phối bị đánh giá thấp

Nomad của HashiCorp đã tồn tại dưới cái bóng của Kubernetes trong nhiều năm, nhưng điều đó đang thay đổi. Kiến trúc của nó đơn giản một cách có chủ ý nhưng vẫn cung cấp sự linh hoạt đáng ngạc nhiên — nó có thể điều phối không chỉ container mà còn cả các ứng dụng truyền thống và các tác vụ batch.

“Nomad đã cung cấp cho chúng tôi 80% những gì chúng tôi cần từ Kubernetes với 20% sự phức tạp,” một kỹ sư chính (principal engineer) có công ty đã chuyển đổi sau khi vật lộn với Kubernetes trong hai năm cho biết. “Đường cong học tập cho đội ngũ của chúng tôi được tính bằng ngày, chứ không phải tháng.”

Điều đặc biệt đáng chú ý là cách Nomad hoạt động tốt với các công cụ khác của HashiCorp như Consul và Vault, tạo ra một hệ sinh thái giải quyết vấn đề khám phá dịch vụ (service discovery) và quản lý secret mà không cần cách tiếp cận “tất cả trong một” của Kubernetes.

Các công ty chưa hoàn toàn container hóa nhận thấy khả năng quản lý các khối lượng công việc hỗn hợp của Nomad đặc biệt có giá trị trong các giai đoạn chuyển đổi.

3. Nền tảng Container Serverless: Google Cloud Run và Azure Container Apps

Mô hình container serverless — điển hình là Google Cloud Run và Azure Container Apps — có lẽ đại diện cho sự thay đổi tư duy ấn tượng nhất so với Kubernetes truyền thống.

Các nền tảng này xử lý việc mở rộng (bao gồm cả việc co về 0), mạng và vận hành môi trường runtime của container với cấu hình tối thiểu. Các nhà phát triển chỉ cần cung cấp một image container, và nền tảng sẽ làm phần còn lại.

“Chúng tôi đã chuyển 70% microservices của mình từ GKE sang Cloud Run,” một giám đốc kỹ thuật nền tảng tiết lộ. “Các triển khai mà trước đây liên quan đến việc sửa đổi nhiều tài nguyên Kubernetes giờ đây chỉ cần một lệnh duy nhất. Các kỹ sư của chúng tôi không còn phải lo lắng về pods và bắt đầu tập trung vào các dịch vụ thực tế của họ.”

Sự chấp nhận nhanh chóng của các nền tảng này báo hiệu một mong muốn rõ ràng trên thị trường về các tùy chọn triển khai container được đơn giản hóa triệt để. Sự đánh đổi là ít linh hoạt hơn trong các lĩnh vực như mạng và lưu trữ, nhưng đối với nhiều dịch vụ stateless, những hạn chế này hiếm khi quan trọng trong thực tế.

4. Kỹ thuật Nền tảng với Nền tảng Nhà phát triển Nội bộ (IDPs)

Một xu hướng thú vị mà tôi quan sát được không phải là một sự thay thế trực tiếp cho Kubernetes mà là một lớp bên trên nó: các nền tảng nhà phát triển nội bộ (internal developer platforms) trừu tượng hóa sự phức tạp của hạ tầng.

Các công cụ như Backstage, Porter và Humanitec đang ngày càng được áp dụng như những cách để cung cấp khả năng tự phục vụ cho các nhà phát triển mà không làm lộ ra sự phức tạp bên dưới của Kubernetes. Một số công ty thậm chí còn xây dựng các nền tảng tùy chỉnh phù hợp với nhu cầu cụ thể của họ.

“Chúng tôi giữ Kubernetes nhưng làm cho nó ‘vô hình’ đối với hầu hết các kỹ sư của chúng tôi,” một trưởng nhóm nền tảng tại một doanh nghiệp lớn giải thích. “Nền tảng nội bộ của chúng tôi cung cấp khả năng triển khai chỉ bằng một nút bấm trong khi nhóm nền tảng xử lý tất cả sự phức tạp. Các nhà phát triển không còn phải viết một dòng YAML nào nữa.”

Cách tiếp cận này cho phép các tổ chức duy trì sức mạnh của Kubernetes trong khi giải quyết các thách thức về khả năng sử dụng của nó. Nó đòi hỏi đầu tư vào kỹ thuật nền tảng nhưng có thể cải thiện đáng kể trải nghiệm của nhà phát triển.

5. Cách tiếp cận “Ít hơn là nhiều hơn”: Container hóa mà không cần Orchestration

Có lẽ đáng ngạc nhiên nhất là số lượng ngày càng tăng các công ty quay trở lại các mô hình triển khai đơn giản hơn — chạy container trực tiếp trên máy ảo với các công cụ điều phối cơ bản như Docker Compose cho phát triển cục bộ và systemd hoặc supervisor cho production.

“Chúng tôi đã xem xét kỹ lưỡng nhu cầu thực tế của mình và nhận ra rằng chúng tôi đang dùng búa tạ để đóng một cái đinh ghim,” một CTO của startup nói. “Hầu hết các dịch vụ của chúng tôi không quá phức tạp và không cần mở rộng quy mô động hoặc mạng nâng cao. Chạy container trên VM với giám sát tốt và tự động hóa triển khai mang lại cho chúng tôi 90% lợi ích với 10% rắc rối.”

Cách tiếp cận này hoạt động đặc biệt tốt cho các đội nhỏ hơn và các công ty có chu kỳ triển khai truyền thống hơn thay vì các pipeline triển khai liên tục đẩy hàng chục bản cập nhật mỗi ngày.

Đưa ra lựa chọn đúng đắn cho đội của bạn

Việc rời xa Kubernetes không có nghĩa đó là lựa chọn sai lầm cho tất cả mọi người. Các tổ chức có sự kết hợp phù hợp giữa quy mô, mức độ trưởng thành trong vận hành và độ phức tạp thực sự hưởng lợi từ các khả năng của nó.

Nhưng đối với nhiều người khác, khung làm việc sau đây có thể giúp xác định liệu một lựa chọn thay thế có tốt hơn hay không:

• Hãy thành thật về quy mô của bạn. Bạn đang chạy hàng trăm microservices trên nhiều khu vực, hay kiến trúc của bạn vẫn còn tương đối đơn giản? Các triển khai nhỏ hơn hiếm khi biện minh cho sự phức tạp của Kubernetes.
• Đánh giá năng lực vận hành của đội ngũ bạn. Bạn có các kỹ sư nền tảng chuyên trách có thể quản lý Kubernetes, hay các nhà phát triển của bạn đang kiêm nhiệm nhiều vai trò? Các đội thiếu nhân sự sẽ gặp khó khăn với chi phí vận hành của K8s.
• Đánh giá nhu cầu điều phối thực tế của bạn. Bạn có yêu cầu các tính năng nâng cao như tự động mở rộng, mạng phức tạp và quản lý tài nguyên, hay một giải pháp đơn giản hơn có thể đủ?
• Xem xét tần suất triển khai của bạn. Các tổ chức đẩy nhiều bản triển khai hàng ngày hưởng lợi nhiều hơn từ khả năng tự động hóa của Kubernetes so với những người triển khai hàng tuần hoặc hàng tháng.
• Tính đến các khoản đầu tư hiện có của bạn. Nếu bạn đã đầu tư nhiều vào chuyên môn và công cụ Kubernetes, chi phí chuyển đổi có thể lớn hơn lợi ích tiềm năng.

Tương lai của điều phối container

Quả lắc dường như đang quay trở lại sự đơn giản, với nhiều tổ chức quyết định rằng sự phức tạp đầy đủ của Kubernetes mang lại lợi ích ngày càng giảm dần cho các trường hợp sử dụng cụ thể của họ.

Điều này không có nghĩa là Kubernetes sẽ bị diệt vong, mà gợi ý một tương lai nơi nó chia sẻ không gian điều phối với các lựa chọn thay thế chuyên biệt thay vì thống trị hoàn toàn.

Kết quả có khả năng nhất là sự phân tầng lớn hơn: các doanh nghiệp có nhu cầu phức tạp và các đội nền tảng chuyên trách sẽ tiếp tục sử dụng Kubernetes, trong khi các công ty tìm kiếm thời gian ra thị trường nhanh hơn và chi phí vận hành thấp hơn sẽ ngày càng lựa chọn các giải pháp thay thế tinh gọn.

Như với tất cả các lựa chọn công nghệ, không có câu trả lời đúng duy nhất — chỉ có những đánh đổi phải được đánh giá dựa trên ngữ cảnh, ràng buộc và mục tiêu cụ thể của tổ chức bạn.

Cuộc “di cư thầm lặng” khỏi Kubernetes dạy chúng ta một bài học quan trọng: đôi khi giải pháp “tiêu chuẩn ngành” không phải là giải pháp phù hợp cho nhu cầu cụ thể của bạn. Có dũng khí để lùi lại và đánh giá lại các lựa chọn công nghệ, ngay cả sau khi đã đầu tư đáng kể, là điều phân biệt các tổ chức thực sự thích nghi với những tổ chức bị mắc kẹt trong các mô hình lợi nhuận giảm dần.