Đừng dùng Kubernetes quá sớm
(matt-rickard.com)Các startup đang ở giai đoạn đầu đừng vội triển khai Kubernetes.
Trong большинстве trường hợp, đây là quyết định quá sớm.
Với các nhóm nhỏ (1~10 người), nên dùng dịch vụ container serverless.
(AWS ECS - Fargate, Google Cloud Run của GCP)
13 bình luận
Chẳng phải k8s giờ đã không còn là vấn đề thích hay không thích nữa, mà là vấn đề sống còn sao?
Tôi nghĩ dù có thể không biết AWS, thì cũng đã đến mức buộc phải biết k8s rồi.
Tôi phản đối ý kiến này.
Tôi cho rằng nhược điểm duy nhất của k8s chỉ là đường cong học tập.
Ngay cả khi đội chỉ khoảng 5 người, lúc đầu sẽ khó thật, nhưng một khi mức độ thành thạo về k8s đã vượt qua một ngưỡng nhất định thì tuyệt đối không thể quay lại cách cũ được. Mức cải thiện năng suất nhờ đó là không thể so sánh.
ci/cd,gitops, triển khai canary v.v. đều có thể làm mà không cần k8s, nhưng thực hiện cùng trên nền k8s thì dễ hiểu hơn và quản lý cũng thuận tiện hơn.Với tôi, người đã trực tiếp trải qua quá trình chuyển đổi, việc nói rằng vẫn còn quá sớm
giống như gợi nhớ đến thời kỳ on-premise khi người ta còn chần chừ áp dụng AWS Cloud chỉ vì cảm thấy xa lạ.
Đây không phải kiểu lập luận chung chung như “hãy tập trung vào kinh doanh”, mà là tôi khó đồng ý với những quyết định dẫn tới bị khóa chặt vào một công nghệ đặc thù nào đó.
Nếu đây là bài viết khuyên nên tích cực tận dụng các PaaS như beanstalk/app engine/heroku thì tôi sẽ rất đồng tình, nhưng hiện nay các lợi thế mà một đội nhỏ có thể đạt được khi chọn ECS/cloud run/docker swarm gần như không còn nữa. Có lẽ nếu là 4~5 năm trước thì còn khác.
Xét về chi phí thì serverless vượt trội áp đảo.
Tôi cũng đồng cảm. Trong đa số trường hợp,
docker-swarmhoặcdocker-composelà quá đủ rồi.Đây cũng là ý kiến xuất hiện rất nhiều trong các bình luận trên Hacker News..... [1]
Tôi thấy hơi khó hiểu vì bài viết mặc định tiền đề là "Kubernetes rất khó".
Dạo gần đây hệ sinh thái Kubernetes đã phát triển rất nhiều, nên trừ khi tự cài Kubernetes trực tiếp trên on-prem thì nó không đến mức khó như vậy.
Ngoài ra, khi vận hành Kubernetes, mức độ phức tạp cũng có thể tự quyết định ở một mức nào đó; để dựng cấu hình cơ bản thì không quá vất vả. Tất nhiên về sau nếu gắn thêm đủ thứ addon thì sẽ khó hơn.
Giờ cũng có nhiều người giống tôi, ngay từ thời mới vào nghề đã trải nghiệm môi trường triển khai bắt đầu từ EKS.
Nói đúng trọng tâm thì,, tôi không hiểu việc cấu hình các thành phần k8s cơ bản như Deployment, Ingress (tất nhiên DB là một dịch vụ managed riêng) lại khó hơn hẳn so với việc tự cấu hình AWS ECS Fargate như bài kia nói ở điểm nào.
Dù sao thì cả hai bên đều phải cấu hình VPC, cluster, CDN, load balancer như nhau mà... Trong phần bình luận thậm chí còn có nhiều ý kiến nói ECS còn bất tiện hơn.
[1] https://news.ycombinator.com/item?id=31795160
Tôi đồng ý. Tôi nghĩ việc thiết lập cơ bản không đến mức khó như vậy, và độ khó bảo trì cũng không phải là cao. Dù chuyển một thiết lập phức tạp trên cloud sang thiết lập
ymlcủa Kubernetes thì cũng khó mà nói là có gì tốt hơn hẳn.Công ty chúng tôi đang chuyển từ ECS sang EKS vì khi số lượng lập trình viên đã vượt quá 100 người thì bắt đầu cảm thấy cần thiết, nhưng đôi lúc cũng thấy hơi hối tiếc.
Mọi người nói rằng "độ phức tạp khi vận hành Kubernetes có thể tự quyết định ở một mức độ nào đó", nhưng từ góc nhìn của người chưa hiểu rõ thì lại dễ nghĩ rằng những gì được nhắc đến trong hệ sinh thái Kubernetes chắc hẳn đều cần thiết, rồi cuối cùng đưa hết vào.
Có nói rằng việc phải cấu hình load balancer thì vẫn như nhau, nhưng tôi nghĩ vẫn có khác biệt giữa việc chỉ cần biết ALB và việc phải hiểu cả ALB + Ingress.
Cũng giống như ở quy mô nhỏ thì chưa cần MSA, Kubernetes có nhiều thứ phải biết hơn so với tưởng tượng, nên tôi nghĩ ở quy mô mà "cần tập trung vào ứng dụng" thì đúng là hơi quá tầm cần thiết.
Tuy vậy, nếu ai đó đã xây dựng tốt môi trường Kubernetes, thì việc triển khai ứng dụng trên đó được định nghĩa bằng cách diễn đạt độc lập với cloud, nên có vẻ hiệu ứng lock-in sẽ ít hơn.
Nghe bạn nói thì đúng là có vẻ chắc chắn có những khía cạnh như vậy. Có lẽ tôi đã xem những điều mình học được khi dùng Kubernetes là quá hiển nhiên.
Và tôi cũng thừa nhận rằng dạo này có quá nhiều add-on xuất hiện trong Kubernetes nên việc chọn lọc cái nào dùng cũng khá khó khăn.
Vì tôi chưa có kinh nghiệm migration kiểu ECS -> EKS nên... ngoài hiệu ứng lock-in ra, tôi muốn hỏi là sau khi chuyển đổi thì có điểm gì được cải thiện hơn không?
À, xin lưu ý là kinh nghiệm của tôi ở đây được nói dựa trên EKS. Nó khá khác với việc tự cài k8s on-prem và tự vận hành etcd, Control Plane nhé haha.
Từ góc nhìn của một người bắt đầu luôn với k8s, khi đọc bài này tôi lại có suy nghĩ ngược lại là có thật sự cần bỏ thời gian học ECS hay không...
Dù sao thì tôi nghĩ cũng không nhất thiết phải chính thức quy định như vậy, mà trước hết cứ dùng theo cách mà đội ngũ cảm thấy thuận tiện là đúng hơn.
Tôi đồng ý với quan điểm nên bắt đầu với k8s.
Tôi rất đồng cảm.
Không chỉ với đội ngũ 10 người, tôi còn khá phản đối việc đưa k8s vào ở những công ty có quy mô tầm trung.
Tôi nghĩ chỉ khi mức độ vendor lock-in với nhà cung cấp cloud trở nên nghiêm trọng, hoặc khi hạ tầng như on-prem cũng được sử dụng song song, thì việc đó mới thực sự có ý nghĩa.
Tôi từng nghĩ đúng là có phần chúng ta đang quán tính chạy theo tech stack của các công ty cấp enterprise.
Đúng lúc có một bài viết tổng hợp lại chuyện này xuất hiện trên Hacker News nên chia sẻ với mọi người.