현재 버전

모놀리식으로 가다가 하나 하나 분리해 나가다 보면 MSA가 되는거죠. MSA는 도입할지 안할지를 결정해야하는 '기술 스택'같은게 아니라, 대규모 서비스 (조직이 대규모이든, 단일 도메인이 대규모이든, 소스 레포가 대규모이든) 가 지향해야할 아키텍쳐'론'이라고 생각합니다. 

MSA가 왜 존재하는지에 대한 이유 없이, 다른 유명한 서비스는 MSA 로 이런부분이 좋았다는데 왜 우리는 저렇게 안될까를 고민하기 시작하면 희망고문이겠네요.

애시당초에 한국에서 MSA를 논해야할 정도로 대규모인 서비스가 몇개나 될까요. 서비스의 크기도 그렇지만, 남한에서 서비스 런칭하는 정도라면 클라우드 리전 하나로 커버됩니다. 트래픽 늘어나면 단일 리전 내에서 스케일링해버리면 문제 없죠. 북미같은 경우엔 서비스 자체는 대규모가 아니어도 디플로이/테스트/스케일링을 생각하면 컨테이너(K8s)와 MSA를 고려하는 곳도 있는 것 같습니다. 한국 국내서비스에선 여러 리전에 디플로이/테스트/스케일링 할 고민을 하지 않아도 되니 MSA 고민해야할 이유가 하나 더 적어집니다.

MSA철학에 준거해서 도메인을 잘게 나누어서 각각을 서비스로 하려고 하면, 손 정말 많이 갑니다. 필요에 따라 거대 도메인이 생기지 않을정도로 나누면 충분할 것 같군요.


수정 이력

2022-04-12 17:09:46 에 아래 내용에서 변경 됨 #2

모놀리식으로 가다가 하나 하나 분리해 나가다 보면 MSA가 되는거죠. MSA는 도입할지 안할지를 결정해야하는 '기술 스택'같은게 아니라, 대규모 서비스 (조직이 대규모이든, 단일 도메인이 대규모이든, 소스 레포가 대규모이든) 가 지향해야할 아키텍쳐'론'이라고 생각합니다. 

MSA가 왜 존재하는지에 대한 이유 없이, 다른 유명한 서비스는 MSA 로 이런부분이 좋았다는데 왜 우리는 저렇게 안될까를 고민하기 시작하면 희망고문이겠네요.

애시당초에 한국에서 MSA를 논해야할 정도로 대규모인 서비스가 몇개나 될까요. 서비스의 크기도 그렇지만, 남한에서 서비스 런칭하는 정도라면 클라우드 리전 하나로 커버됩니다. 트래픽 늘어나면 단일 리전 내에서 스케일링해버리면 문제 없죠. 여러 리전에 디플로이/테스트/스케일링 할 고민을 하지 않아도 되니 MSA 고민해야할 이유가 하나 더 적어집니다.

MSA철학에 준거해서 도메인을 잘게 나누어서 각각을 서비스로 하려고 하면, 손 정말 많이 갑니다. 필요에 따라 거대 도메인이 생기지 않을정도로 나누면 충분할 것 같군요.

2022-04-12 17:08:27 에 아래 내용에서 변경 됨 #1

모놀리식으로 가다가 하나 하나 분리해 나가다 보면 MSA가 되는거죠. MSA는 도입할지 안할지를 결정해야하는 '기술 스택'같은게 아니라, 대규모 서비스 (조직이 대규모이든, 단일 도메인이 대규모이든, 소스 레포가 대규모이든) 가 지향해야할 아키텍쳐'론'이라고 생각합니다. 

MSA가 왜 존재하는지에 대한 이유 없이, 다른 유명한 서비스는 MSA 로 이런부분이 좋았다는데 왜 우리는 저렇게 안될까를 고민하기 시작하면 희망고문이겠네요.

애시당초에 한국에서 MSA가 절실할 정도로 대규모인 서비스가 몇개나 될까요. 서비스의 크기도 그렇지만, 남한에서 서비스 런칭하는 정도라면 클라우드 리전 하나로 커버됩니다. 트래픽 늘어나면 단일 리전 내에서 스케일링해버리면 문제 없죠. 여러 리전에 디플로이/테스트/스케일링 할 고민을 하지 않아도 되니 MSA 고민해야할 이유가 하나 더 적어집니다.

MSA철학에 준거해서 도메인을 잘게 나누어서 각각을 서비스로 하려고 하면, 손 정말 많이 갑니다. 필요에 따라 거대 도메인이 생기지 않을정도로 나누면 충분할 것 같군요.