클러치 프로젝트 리팩토링을 시작하기에 앞서 더 나은 관리 방법에 관심이 생겨 MSA 설계 유형에 대해 공부를 시작하게 되었다. 이에 대한 공부는 '도커, 쿠버네티스, 테라폼으로 구현하는 마이크로서비스'라는 책을 정해 하려고 한다
지속적으로 앱을 개발하고 향상시키려면 고객의 요구를 감당할 수 있는 확장성도 지녀야 한다고 생각한다. MSA 설계 방식은 기존의 모놀리스 앱보다 어렵고 복잡하며 시간이 많이 소요되는 설계 방식이다.
최근 개발 생태계는 접근성 좋고 저렴한 클라우드 인프라 비용과 예전보다 더욱 향상된 도구들과 자동화에 대한 수요 증가 등의 다양한 여건이 맞아떨어진다. 앱은 복잡해지지만, MSA는 복잡성을 더 잘 관리할 방법을 제공한다.
이
마이크로서비스는 개별젹으로 배포 일정을 갖고 업데이트 운영이 가능한 작고 독립적인 소프트웨어 프로세스이다.
마이크로서비스 앱은 프로젝트의 주요 기능들을 수행하기 위해 서로 협업하는 작은 서비스들로 구성된 분산 프로그램
클러스터는 클러스터 오케스트레이션 플랫폼 위에 존재한다. 오케스트레이션은 서비스들에 대한 자동화된 관리를 말한다.
클러스터, 데이터베이스,가상 인프라 모두 우리가 선택한 클라우드 서비스에 존재한다.
모놀리스는 전체적인 앱이 단일 프로세스로 동작하는 경우를 말한다
담당자의 변경이 있을 때, 시간이 지나면서 앱의 목표가 희미해질때 코드들이 중구난방으로 될 가능성이 크다.
하지만 모놀리스는 새로운 앱을 만들 때 좋은 시작점이기도 해서 마이크로서비스 앱이 요구하는 많은 기술적 투자를 시행하기 이전의 초기 단계라고 가정하면 비즈니스 모델의 유효성을 테스트하기 적합하다
그래서 모놀리스는 나중에 버릴 수 있는 실험적 모델을 만들어보기에 적합하다. 작은 범위에서 또는 나중에 추가적인 기능 확장이 필요 없이 빠르게 잘 동작하게 만들려는 앱들을 모놀리스로 만들기에 적합하다.
도커:패키지를 만들거나 서비스를 배포한다, 도커 컴포즈:개발 환경에서 마이크로서비스 앱을 테스트한다, 쿠버네티스: 클라우드에 앱을 호스트한다, 테라폼: 클라우드 인프라, 쿠버네티스 클러스터를 만들고 앱을 배포한다
비즈니스 영역과 소프트웨어로서의 비즈니스를 이해하는 방법
DDD의 의미적 구분은 마이크로서비스의 구성에 적합하다
많은 개발자들은 DRY(Don't Repeat Yourself)라는 원칙을 안고 살지만 마이크로서비스 분야에서는 반복되는 코드들이 등장한다
따라서 DRY의 원칙은 포기하지 않고 반복되는 코드가 존재하는 것이 합리적이라면 그렇게 되도록 할 것이다.