Team của anh em có thực sự cần Kubernetes không, hay chỉ đang “múa” cho đẹp CV?

Bài viết dành cho các bài toán/doanh nghiệp vừa và nhỏ hoặc các anh em đang có suy nghĩ “theo trend” thì nên đọc tham khảo để tối ưu đúng giá trị hơn nhé.

Tuần trước, tôi có lượn qua “chém gió” với một startup fintech Series A. Team cũng ngon, khoảng 10 ông Dev, sản phẩm đang lên. Khi tôi ngó qua cái kiến trúc của họ, thú thật là tôi hơi “ngợp”. Một “combo ăn chơi” đúng nghĩa: cluster EKS 3-node m5.large, giăng cả lưới Istio, chạy GitOps với ArgoCD, rồi thì Prometheus, Grafana đủ cả.

Nhìn thì hoành tráng thật. Nhưng tôi có hỏi 2 câu:

  1. “Bill AWS mỗi tháng ‘bay’ hết bao nhiêu lúa anh?”
  2. “Một ông Dev mới vào team thì mất bao lâu để tự tay đẩy được một cái thay đổi nhỏ lên staging?”

Ông bạn Tech Lead bên này cũng có vẻ hơi đắn đo và nhìn sang ông anh CTO =))). Câu trả lời là: “hơn 70 củ/tháng”“tầm 2 tuần mới dám cho tự deploy”. Ở đây anh em phải xác định được thế nào gọi là ít hay nhiều nhé, có doanh nghiệp đốt cả 2-300 củ/tháng cũng vẫn thấy vừa những có doanh nghiệp đốt 50 củ/tháng nhưng nhìn rõ ràng trông vẫn thấy không đáng.

Anh em thấy quen không? Đây chính là cái bẫy mà rất nhiều team đang tự chui đầu vào. Kubernetes, một con hàng khủng được Google đẻ ra để giải quyết bài toán của nó, giờ lại thành “mốt”. Nhưng nói thẳng ra nhé. Đa phần ôm K8s vào không chỉ là thừa thãi, mà còn là tự rước họa vào thân. Nó chính là màn “dùng dao mổ trâu để giết gà” điển hình nhất.

Cơn đau đầu kinh niên tên là “Phức tạp”

Khi anh em quyết định xài K8s, nó không chỉ là chuyện kubectl apply đâu. Anh em đang tự nguyện ký vào một bản hợp đồng trả góp một thứ thuế vô hình: thuế phức tạp.

Team Dev của anh em, thay vì chỉ cần biết Dockerfile, giờ bị bắt phải “cày” cả một mớ lý thuyết rối não: Pods, Services, Ingress, ConfigMaps, Secrets, vân vân và mây mây. Rồi để cho nó “pro”, lại phải nhồi thêm Helm với Kustomize. Muốn monitor á? Lại phải vọc Prometheus Operator với một rừng CRD của nó. Bảo mật giữa các service? Mời anh xơi Istio, thứ sẽ gắn thêm một cục sidecar vào mỗi pod, nặng gấp đôi và sẵn sàng “thở oxy” bất cứ lúc nào.

Cái gánh nặng này nó đổ hết lên đầu Dev. Thay vì ngồi code ra business, thì các ông lại phải còng lưng đi debug mấy cái file YAML chết tiệt. Mọi thứ tự dưng chậm như rùa.

Tiền “bay màu” lặng lẽ – Những thứ bill AWS không ghi rõ

Mấy sếp hay bảo: “Dùng managed K8s đi cho nhàn!”. Nhàn đâu chưa thấy, chỉ thấy tiền “ngốn” như hack:

  1. Phí “nuôi” Control Plane: Chưa cần chạy cái app nào, anh em đã tự nguyện cúng cho AWS/Google ~70 đô/tháng (bằng cả năm xem Netflix) chỉ để duy trì cái control plane.
  2. Cái ống hút tiền NAT Gateway: Cứ mỗi GB data từ pod chạy ra ngoài Internet qua con NAT Gateway là một lần anh em thấy ví tiền “chảy máu”. Mấy service gọi nhiều API bên ngoài thì xác định.
  3. Sự lãng phí trên từng con Node: Con nào con nấy lúc nào cũng phải chạy một đống thứ linh tinh của K8s. Kết quả là node toàn chạy 30-40% tải, nhưng tiền thì vẫn phải trả đủ 100%. Toàn là tiền đốt đi cho vui.
  4. Lương nuôi “bảo mẫu”: Quan trọng nhất, anh em phải thuê một hoặc vài ông DevOps cứng cựa chỉ để làm “bảo mẫu” cho con K8s này. Lương của các ông này đủ để thuê 2-3 ông Dev ngon đấy.

Năng suất “bốc hơi” và vòng lặp chờ đợi đến phát chán

Đây mới là thứ làm tôi bực mình nhất. So sánh nhẹ nhé:

  • Ngày xưa: Dev sửa code, gõ docker-compose up, 5 giây sau thấy kết quả.
  • Thời K8s: Dev sửa code -> build image -> push -> sửa YAML -> commit -> chờ CI/CD chạy sml -> kubectl apply -> ngồi pha ấm trà chờ Pod lên -> kubectl logs

Cái vòng lặp từ 5 giây nó biến thành 15 phút. Mỗi lần chờ là một lần mất hứng. Một ngày 8 tiếng thì mất toi cả tiếng đồng hồ chỉ để ngồi đợi. Nó bào mòn sự sáng tạo và sự kiên nhẫn của những ông Dev giỏi nhất, chán tới tận cổ. Nhưng mà đương nhiên rồi không thể phủ định sự tiện lợi của K8s.

Thoát khỏi “ma trận” – Có đường khác không?

Giải pháp cho ca này á? Cực đơn giản, quay về với “chân ái”: Sự đơn giản!

  1. Chơi luôn hàng Serverless như AWS Fargate/Google Cloud Run: Mấy con microservices kia vứt hết lên đây. Không cần lo server, trả tiền theo từng giây sử dụng. Bill giảm 70-80% là có thật. Dev chỉ cần biết mỗi Dockerfile. Xong.
  2. Nếu vẫn khoái VM: Lấy 2 con EC2, cài Docker, bật Docker Swarm lên mà chơi. Nó dễ như ăn kẹo mà vẫn mạnh chán. Hoặc dùng Nomad cũng được. Deploy thì viết con script Ansible vài chục dòng là xong. Dev mới vào dí cho cái doc là deploy được luôn trong ngày.

Thế là team có thời gian và tiền bạc để đi làm sản phẩm, thay vì suốt ngày đi “hầu” hạ tầng.

Chốt hạ

Nói thẳng ra nhé, K8s là một công cụ phi thường. Nhưng nó dành cho Netflix, cho Spotify, cho những công ty có bài toán vận hành ở quy mô mà đa số các doanh nghiệp/bài toán nhỏ vửa chúng ta sẽ không bao giờ chạm tới.

Vấn đề của nhiều anh em là đang bị cuốn vào cái gọi là “Resume-Driven Development” – tức là “phát triển hướng-CV”. Chọn công nghệ chỉ vì nó oách, nó sáng CV, chứ không phải vì nó giải quyết được đúng vấn đề.

Lần tới, trước khi áp dụng K8s cho dự án, anh em thử thành thật với chính mình một lần xem: “Mình đang giải quyết vấn đề của công ty, hay chỉ đang ‘múa’ cho bản thân?”. Nhưng cũng lại dẫn đến vấn đề anh em đang nghĩ trong đầu tôi cũng biết là “Dùng docker thuần phù hợp bài toán nhưng ghi vào CV thì không có oai” =)))

Chia sẻ bài viết:
Theo dõi
Thông báo của
0 Góp ý
Được bỏ phiếu nhiều nhất
Mới nhất Cũ nhất
Phản hồi nội tuyến
Xem tất cả bình luận