마이크르서비스 아키텍처의 잠재적 이점을 알아봤다. 그러나 마이크로서비스를 전혀 사용하지 말아야 할 때도 있다.
불분명한 도메인
서비스 경계를 잘못 잡으면 많은 비용이 들 수도 있다. 이로 인해 잦은 서비스 변경이나 과도하게 결합된 구성 요소가 발생할 수 있으며, 단일 모놀리스 시스템을 사용하는 경우보다 더 나빠질 수도 있다. 도메인에 낯선 경우, 너무 조기에 시스템을 마이크로서비스로 분해하면 높은 비용이 발생할 수 있다. 기존 코드 기반을 마이크로서비스로 분해하는 방식이 처음부터 마이크로서비스를 시도하는 방식보다 여러 가지 면에서 훨씬 더 수월하다.
아직 도메인을 완전히 파악하지 못했다고 생각한다면, 시스템 분해에 몰두하기보다는 도메인부터 해결하는 쪽이 바람직하다.
스타트업
마이크로서비스는 최소한 제품/시장 적합성의 기초를 확립해왔고 이제는 수익성을 높일 목적으로 확장에 나서는 '수직 확장'을 위한 훌륭한 선택지가 될 수 있다.
수직 확장까지 갈 길이 먼 스타트업은 고객과 맞아 떨어지는 적합성을 찾기 위해 다양한 아이디어를 실험하곤 한다. 이로 인해 영역을 탐색할 때 제품의 원래 비전에 큰 변화가 생기고, 결과적으로 제품 도메인에도 큰 변화가 일어날 수 있다.
스타트업은 자금이 제한적인 소규모 조직일 가능성이 높으며, 제품을 위해 올바른 적합성을 찾는 과정에 관심을 집중해야 한다. 마이크로서비스는 스타트업으로 초기에 성공하고 난 뒤에 발생할 수 있는 다양한 문제를 해결하는 훌륭한 방법이다. 처음에는 성공에 집중해야 한다. 초기 아이디어가 나쁘면, 마이크로서비스로 구축했는지 아닌지 여부는 전혀 중요하지 않다.
고객 설치형 소프트웨어와 관리형 소프트웨어
소프트웨어를 패키지로 만들어서 직접 운영할 고객에게 출시할 경우, 마이크로서비스는 나쁜 선택일지도 모른다. 고객에게 실행하고 관리할 프로세스를 1개만 제공했는데, 이후에 확장을 위해 10개 또는 20개로 늘어나고 난 뒤를 상상해보자. 고객들이 쿠버네티스 클러스터 또는 이와 유사한 환경에서 소프트웨어를 실행하 것으로 기대하는가? 현실적으로 마이크로서비스 아키텍처를 관리하기 위해 사용 가능한 기술이나 플랫폼을 고객에게 기대할 수 없다. 심지어 고객에게 기술적인 역량이 있을지라도, 우리가 요구하는 동일 기술이나 플랫폼은 없을 수도 있다.
좋은 이유를 못 찾겠다.
마지막으로, 마이크로서비스를 채택하지 않은 가장 큰 이유는 바로 마이크로서비스로 달성하려는 목표가 정확히 무엇인지에 대해 아무 생각이 없기 때문이다. 마이크로서비스 채틱 과정에서 추구하려는 성과를 통해 마이그레이션을 어디서 시작하고 시스템 분해를 어떻게 할지를 정의할 수 있다. 목표에 대해 명확한 비전 없이, 모든 사람이 마이크로서비스를 하기 때문에 따라 한다는 생각은 끔직할 뿐이다.
