아직은 쿠버네티스를 사용하지 마라
(matt-rickard.com)얼리스테이지에 있는 스타트업들은 쿠버네티스를 섣불리 도입하지 마라.
시기상조인 경우가 대부분.
작은 규모의 팀(1~10명)은 Serverless container service를 사용하는 것이 좋다.
(AWS ECS - Fargate, GCP의 Google cloud run)
저는 이 의견에 반대합니다.
k8s가 가지는 유일한 단점은 러닝 커브 딱 하나라고 생각합니다.
팀원이 5명 정도 수준일지라도 처음이야 어렵겠지만, 일정 수준 이상 k8s에 대한 수준이 올라오면, 절때 이전으로 돌아 갈 수 없습니다. 그로 인한 생산성 향상은 비교가 되질 않습니다.
ci/cd, gitops, 카나리 배포 등등 k8s 없이도 할 수 있지만, k8s위에 함께 하는것이 더 이해하기 쉽고 관리하기 간편합니다.
직접 이전기를 경험해본 저로서는 아직 시기 상조라고 말하는것은
마치 aws cloud 가 생소하다고 해서 도입을 망설이던 on premise 시절을 떠올리게 합니다.
"비즈니스에 집중해라" 이런 원론적인 차원의 얘기가 아니라 뭔가 특수한 기술에 락인되는 결정에는 동의하기 어렵네요.
beanstalk/app engine/heroku 같은 PaaS를 적극 활용하라는 글이었다면 적극 동의했을 텐데 작은 팀에서 ECS/cloud run/docker swarm을 선택해서 얻는 장점은 요즘은 거의 없다시피 합니다 . 4~5년 전이었다면 모를까요.
해커뉴스 댓글에도 아주 많이 달린 의견인데..... [1]
글이 "쿠버네티스는 어렵다" 라는 게 전제가 깔려있어서 좀 혼란스럽네요.
요즘은 쿠버네티스 에코시스템이 많이 발전해서 온프렘에서 쿠버네티스를 직접 설치하지 않는 이상 그렇게 어려운 것이 아닙니다.
또한 쿠버네티스 운영은 복잡도를 스스로 어느정도 결정할 수 있는데, 기본적인 구성만 만드는 데는 힘들지 않습니다. 나중에 이것저것 애드온들 붙이면 당연히 힘들어지고요.
저 같이 신입때 EKS 부터 배포환경을 경험한 사람도 많이 생겼고요.
콕 찝에서 말하자면,, 기본적인 k8s Deployment, Ingress (물론 DB는 별도의 매니지드 서비스) 를 구성하는 것이 저기 글에서 말하는 AWS ECS Fargate 를 직접 구성하는 것보다 딱히 어려운 것인지 이해가 가지 않네요.
둘 다 같이 VPC, 클러스터, CDN, 로드밸런서 구성을 해야하는 건 똑같은 걸요...댓글에서는 오히려 ECS가 더 불편했다는 글도 많고요.
동감입니다.기본적인 셋업이 그렇게 어렵지도 않고, 유지보수 난이도가 높은편도 아니라고 생각해요. 클라우드에서 복잡한 셋업 하나, 쿠버네티스 yml 셋업으로 넘기나 딱히 뭐가 더 좋다고 말 못하겠네요.
저희 회사는 개발자가 100명을 넘어가면서 필요성이 느껴져서 ECS -> EKS 전환을 하고 있는데 조금 후회할 때도 있습니다.
"쿠버네티스 운영은 복잡도를 스스로 어느정도 결정할 수 있는데" 라고 하시지만, 잘 모르는 입장에서는 쿠버네티스 생태계에 말이 나오는 것은 다 필요한 것인가보다라고 생각하고 다 넣게되는 측면이 있습니다.
로드밸런서 구성을 해야 하는 건 똑같다고 하셨지만, ALB만 알면 되는 것 vs ALB + Ingress를 알아야 하는 것의 차이가 있다고 생각합니다.
작은 규모에서 MSA가 필요하지 않은 것처럼, 쿠버네티스는 생각보다는 알아야 할게 많아서 '어플리케이션에 집중해야 하는 규모'에서는 오버 스펙은 맞다고 생각합니다.
다만 쿠버네티스 환경을 누군가 잘 구축해뒀다면, 그 위에서 어플리케이션 배포하는 것은 클라우드 독립적인 표현으로 정의하다보니 락인 효과가 적을 것 같긴 했습니다.
말씀들어보니 확실히 그런 측면들이 있을 거 같네요. 제가 쿠버네티스 쓰면서 알게 된 것들을 너무 당연하게 생각한거 같네요.
그리고 요즘 쿠버네티스에서 나오는 애드온들 너무 많다보니 취사선택 결정에 어려움이 있다는 것도 인정하고요.
제가 ECS -> EKS 같이 마이그레이션 경험이 없다보니...혹시 락인 효과 같은 거 말고 전환 이후에 좀 나아진 점이 있으신지 궁금합니다.
아 참고로 제 경험은 EKS 기준으로 말씀드리는겁니다. 온프램에서 직접 k8s 설치해서 etcd, Control Plane 을 직접 운영하는 것과 많이 다르죠 ㅎ
k8s부터 시작한 사람 입장에서는, 글을 읽으면서 드는 생각이 반대로 굳이 ECS를 시간들여가며 공부를 해야하나...라는 생각이 들더라고요.
여튼 꼭 저렇게 공식 지정할 필요 없이 우선 팀에서 편하다고 느끼는 방식으로 쓰는게 맞지 않나 생각합니다.
매우 공감갑니다.
10명 뿐만 아니라 어지간한 크기의 회사에서 k8s 도입하는 것에 저는 부정적입니다.
클라우드 벤더 락인이 크리티컬한 수준이 되거나 온프람등의 인프라가 함께 사용되는 수준이나 되야 의미있지 않나 싶습니다.
엔터프라이즈급 회사들의 기술스택을 관성적으로 따라가는 면이 없잖아 있다고 생각했었는데
마침 글로 정리된 게 해커뉴스에 떠서 공유해봅니다