도입 시기를 결정하기 어렵다
애플리케이션 수명 주기 중 어느 시점에 마이크로서비스 아키텍처를 도입할지 결정하는 일도 만만찮습니다. 초기 버전을 개발할 때에는 굳이 마이크로서비스 아키텍처를 사용해서 해결할 이슈가 거의 없습니다. 오히려 정교한 분산 아키텍처를 사용하면 개발 속도가 더딜 수 있고 신속하게 이터레이션(iteration, 반복)하기도 어렵습니다. 따라서 비즈니스 모델과 이를 뒷받침하는 애플리케이션을 재빠르게 발전시켜야 하는 스타트업 회사는 모놀리식 애플리케이션으로 시작하는 것이 좋습니다.
그런 다음 복잡성을 다루는 문제가 중요해지는 시점에 애플리케이션을 여러 마이크로서비스로 기능 분해하는 것이 바람직합니다. 물론 디펜던시가 얽혀 있어서 리팩터링 작업이 만만찮을 수도 있습니다(모놀리스를 마이크로서비스로 리팩터링하는 전략은 13장에서 다룹니다).
이처럼 마이크로서비스 아키텍처는 장점도 많지만 중요한 단점도 있기 때문에 가벼이 도입할 그릇은 아닙니다. 하지만 일반 소비자를 상대하는 웹 애플리케이션이나 SaaS처럼 복잡한 애플리케이션은 대개 마이크로서비스 아키텍처가 잘 맞습니다. 이베이(eBay),9 아마존 닷컴(Amazon.com), 그루폰(Groupon), 길트(Gilt) 같은 유명 사이트도 처음에는 모놀리식 아키텍처로 시작했다가 나중에 마이크로서비스 아키텍처로 전환했습니다.
여러분은 마이크로서비스 도입에 따른 다양한 설계/아키텍처 이슈를 해결해야 하며, 그중 상당수는 솔루션이 한두 가지가 아니고 각자 나름대로 트레이드오프(trade-off)가 있습니다. 완벽한 정답은 없죠. 그래서 필자는 여러분이 올바른 의사 결정을 할 수 있도록 마이크로서비스 아키텍처 패턴 언어(pattern language)를 창조했습니다. 이 패턴 언어는 앞으로 이 책에서 마이크로서비스 아키텍처를 설명하면서 하나씩 선보일 것입니다.