마이크로 서비스 도입 이렇게 한다

마이크로서비스는 SOA의 한 유형이고 비즈니스 도메인을 중심으로 모델링된 독립적으로 배포 가능한 서비스다. 기술 관점에서 마이크로서비스는 하나 이상의 네트워크 종단점을 통해 캡슐화되는 비즈니스 기능을 외부에 공개한다. 또한 잘 정의된 인터페이스를 통해, 데이터 저장소와

이 책에서 모놀리스라고 하면, 주로 배포 단위를 말하는 것이다. 시스템의 모든 기능을 함께 배포해야 할 때, 이를 모놀리스로 간주한다. 이를 만족하는 모노릴스 시스템은 최소 3가지 유형이다.단일 프로세스 시스템분산 모놀리스 시스템외부 블랙박스 시스템가장 일반적으로 생각

마이크로서비스 경계를 정의할 때 결합도와 응집력 사이의 균형을 이해해야 한다. 결합도는 한 가지를 바꾸면 다른 것도 바꿀 필요가 있는 방식을 말하며, 응집력은 관련된 코드를 그룹으로 묶는 방식을 뜻한다. 두 개념은 직접적으로 연결되어 있다. 콘스탄틴의 법칙에서 둘 사이

비즈니스 도메인을 중심으로 서비스를 모델링하면 마이크로서비스 아키텍처에 엄청난 장점이 생긴다. 문제는 이 모델을 구현하는 방법인데, 여기서 도메인 주도 설계(DDD)가 등장한다.도메인 주도 설계에서 집계는 다소 혼란스러운 개념이며, 다양한 정의가 존재한다. 이 책에서는

마이크로서비스는 목표가 아니다. 마이크로서비스 아키텍처 채택은 합리적인 의사결정에 기반한 의도적인 결정이어야 한다. 현재 기존 시스템 아키텍처로는 이룰 수 없는 뭔가를 달성하기 위해, 마이크로서비스 아키텍처로 마이그레이션하는 전략을 고려해야 한다.마이크로서비스가 다른

팀 자율성 향상 자율 팀을 만들고 팀끼리 긴밀한 유대 관계를 구축하고, 관료 절차에 얽매이지 않고 협업함으로써, 그렇지 않은 조직에 비해 더 효과적으로 성장하고 확장해왔다. 자율적 팀이 제대로 작동한다면, 팀 자율성은 구성원에게 힘을 실어주고 성장시키며, 더 빠른 업무

마이크르서비스 아키텍처의 잠재적 이점을 알아봤다. 그러나 마이크로서비스를 전혀 사용하지 말아야 할 때도 있다.서비스 경계를 잘못 잡으면 많은 비용이 들 수도 있다. 이로 인해 잦은 서비스 변경이나 과도하게 결합된 구성 요소가 발생할 수 있으며, 단일 모놀리스 시스템을

현실에서 사람들이 한 가지가 아니라 여러 가지를 동시에 바꾸려고 시도한다. 이로 인해, 필요한 변경 범위가 빠르게 늘어나고 혜택을 보는 시점을 지연시킬 수 있는 우선순위 혼동이 발생한다.예를 들면 다음 상황과 같다. 늘어나는 트래픽 증가를 처리하기 위해 애플리케이션의

"팀원들에게 마이크로서비스를 어떻게 납득시켜야 하나요?"라는 질문은 일반적으로 마이크로서비스 아키텍처의 잠재력을 깨닫고 그것이 미래로 나아가는 길이라고 확신하는 개발자로부터 나온다.팀원들과 어떤 접근 방식이나 달성하려는 목표에 대해 견해가 다를 수 있다. 여정을 함께해

빅뱅 방식으로 백날 해봐야, 빅뱅만 나올 뿐이다.                                                                                                          \- 마틴 파울러기존 모놀리스

우리가 시작해야 할 지점은? 목표를 명확하게 표현하고 잠재적인 상충 관계를 이해하는 것의 중요성을 알았다면, 이제는 서비스를 추출하기 원하는 기능에 대한 자신만의 시각을 구축해야 한다. 그래야 다음에 마이크로서비스에 대해 합리적으로 생각할 수 있기 때문이다. 기존의 모

이 책 전반에서 작고 점진적인 변화를 해야 한다고 강조하는 데에 여러 이유가 있지만, 무엇보다도 중요한 것은 우리가 수행한 변경의 영향력을 이해하고, 필요한 경우 방향을 바꿔야 하기 때문이다. 이로써 실수에 따른 추가 비용 상승을 효과적으로 완화할 수 있지만, 실수할