⭐ 전통적인 폭포수 개발 방법론
전통적인 폭포수 개발 방법론은 프로젝트의 소프트웨어 산출물이 가진 세분화 정도에 따라 다음 단점이 발생한다.
✏️ 강한 결합 (tightly coupled)
비즈니스 로직 호추링 SOAP 이나 REST 같은 중립적인 프로토콜이 아닌 프로그래밍 언어 수준에서 이루어진다. 따라서 애플리케이션 컴포넌트를 조금만 수정해도 애플리케이션의 다른 부분에 문제가 생길 수 있다.
✏️ 누설 (leaky)
대부분의 대규모 소프트웨어 애플리케이션은 다양한 유형의 데이터를 취급한다. 예를 들어 CRM은 고객, 판매, 제품 정보를 관리하는데 전통적 모델에선 이러한 데이터는 같은 레포지터리 안에서 같은 모델을 유지한다. 따라서 한 영역에 속한 팀이 다른 팀의 데이터에 직접적으로 접근하고 싶은 유혹을 받는다. 이렇게 되면 보이지 않는 의존성이 생겨나고 컴포넌트 내부 데이터 구조에 대한 세부 구현이 애플리케이션 전체에 유출될 수 있다. DB 테이블 하나만 수정해도 엄청난 코드 수정과 회귀 테스팅이 필요하다.
✏️ 모놀리식
전통적인 애플리케이션에선 대부분의 컴포넌트를 여러 팀에서 공유되는 단일 코드 베이스에 저장하므로 코드를 변경할 때마다 전체 애플리케이션을 재컴파일하고, 통합 테스팅을 수행하고 배포해야 한다.
⭐ 마이크로서비스 기반 아키텍쳐
이러한 단점을 극복하기 위해 마이크로서비스 기반 아키텍처는 기증을 제공하는 데 다음과 같이 접근한다.
✏️ 제한 (Constrained)
마이크로서비스는 하나의 책임 집합을 가지며 범위가 좁다.
✏️ 느슨한 결합 (loosely coupled)
마이크로서비스 기반 애플리케이션은 작은 서비스 집합이며, HTTP와 REST처럼 비독점적 호출 프로토콜을 사용하는 구현 기술에 중립적인 인터페이스로 소통한다.
✏️ 추상화 (abstract)
마이크로서비스는 자신의 데이터 구조와 데이터 소스를 완전히 소유한다. 일반적으로 마이크로서비스의 데이터를 보관하는 DB는 해당 서비스에서만 접근하기 때문이다.
✏️ 독립적 (independent)
마이크로서비스 애플리케이션의 모든 마이크로서비스는 서로 독립적으로 컴파일하고 배포할 수 있다.
⭐ 클라우드 기반 MSA의 특징
✏️ 사용자층이 다양하며 대규모다
마이크로서비스는 작은 범위를 담당하고, 명확히 정의된 인터페이스를 통해 접근하므로 기능을 신속히 제공할 수 있다.
✏️ 상당한 작동 시간 (uptime)이 요구된다
마이크로서비스는 애플리케이션 전체를 중단하지 않고도 고장과 문제를 격리할 수 있다.
✏️ 볼륨이 균일하지 않다
마이크로서비스는 독립적으로 배포가 가능한 작은 컴포넌트로 분리되어 있기 때문에 부하를 받는 컴포넌트를 조명하고 여러 서버에 수평 확장하기 수월하다.
