마이크로서비스

3. 철학

마이크로서비스 아키텍처의 철학은 "한 가지 일을 하되 잘하라"(Do one thing and do it well^영어)는 유닉스 철학과 맞닿아 있다.^{[74][75][76][53]} 이는 각 서비스가 특정 기능 하나에 집중하여 그 기능을 가장 효과적으로 수행하도록 설계되어야 함을 의미한다.^[74][75][76]

이러한 철학에 따라 마이크로서비스는 다음과 같은 특징을 지향한다.

• 작은 크기와 명확한 책임: 각 서비스는 크기가 작으며, 하나의 기능을 수행하는 데 집중한다.^[74][75][76]
• 독립성과 유연성: 각 서비스는 독립적으로 개발, 배포, 확장될 수 있으며, 유연하고 회복력이 있어야 한다. 또한, 필요한 최소한의 기능으로 완전한 서비스를 구성한다.^[76]
• 자동화 문화: 조직 문화는 테스트와 배포 과정의 자동화를 적극적으로 수용해야 한다. 이는 관리 및 운영 부담을 줄이고 개발팀이 독립적으로 서비스를 관리할 수 있게 한다.^[77]
• 실패 수용: 안티프래질 시스템과 유사하게, 시스템의 실패나 서비스의 고장을 예상하고 이를 자연스럽게 받아들이는 문화와 설계 철학이 요구된다.^[74][75][76]

4. 특징

마이크로서비스의 속성에 대해 아직 업계 전반의 합의나 공식적인 정의는 없다.^[45] 그럼에도 불구하고 자주 언급되고 정의되는 특징들은 다음과 같다.

• 마이크로서비스 아키텍처(MSA)의 서비스들은 독립적으로 배포될 수 있다.^{[68][59][50][51]} 이는 애플리케이션의 작은 부분을 변경할 때, 전체 애플리케이션이 아닌 해당 서비스 또는 소수의 서비스만 다시 빌드하고 배포하면 된다는 의미이다.^[64][59]
• 서비스는 쉽게 교체될 수 있다.
• 서비스는 비즈니스 기능별로 구성된다. 예를 들어, 사용자 인터페이스 프론트엔드, 추천 시스템, 물류 관리, 청구서 발급 등으로 나눌 수 있다.^[46] 마이크로서비스에서 기능의 세분화는 중요한데, 이는 서비스 지향 아키텍처(SOA)와 구별되는 특징 중 하나이다.
• 각 서비스는 해당 기능에 가장 적합한 프로그래밍 언어, 데이터베이스, 하드웨어 및 소프트웨어 환경을 사용하여 독립적으로 개발될 수 있다.^[59][51] 이는 특정 기술 선택이 시스템 전체에 영향을 미치는 전통적인 방식과 다르다.^[78]
• 서비스들은 일반적으로 크기가 작고, 메시지 전달을 통해 통신하며, 컨텍스트 경계가 명확하고, 자율적으로 개발된다. 또한, 자동화된 빌드 및 자동화된 릴리스 프로세스를 통해 배포된다.^[68][50]
• 서비스 간 통신은 HTTP와 같은 특정 기술에 얽매이지 않는 프로토콜을 사용하여 네트워크를 통해 이루어지는 경우가 많지만,^{[63][64][65][66][46][47][48]} 공유 메모리와 같은 다른 프로세스 간 통신 메커니즘이나,^[67][49] OSGi 번들처럼 동일한 프로세스 내에서 실행될 수도 있다.

• 자연스럽게 모듈성이 있는 구조를 강제한다.^[64][46]
• 지속적 배포 소프트웨어 개발 프로세스에 적합하다.^[64][59][46]
• 세분화된 인터페이스(독립적으로 배포 가능한 서비스), 비즈니스 주도 개발(예: 도메인 주도 설계), 클라우드 애플리케이션 아키텍처, 폴리곳 프로그래밍 및 퍼시스턴스, 가벼운 컨테이너 배포, 탈중심화된 지속적 배포, 전체론적인 서비스 모니터링을 갖춘 데브옵스와 같은 원칙들을 고수한다.^[69][46]
• 확장성에 이점을 제공한다.^[70][71][72]

• 서비스의 크기는 작으며, 하나의 기능을 수행하는 데 집중한다(세분화, fine-grained).
• 조직 문화는 테스트 및 배포의 자동화를 수용해야 한다. 이는 관리 및 운영 부담을 줄이고 개발팀들이 독립적으로 작업할 수 있게 한다.^[77]
• 문화와 설계 철학은 안티프래질 시스템과 유사하게 실패와 고장을 예상하고 수용해야 한다.
• 각 서비스는 유연하고, 회복력 있으며, 구성 가능하고, 최소한의 기능으로 완전하게 설계된다.^[76]

• 서비스의 컴포넌트화: 서비스는 독립적으로 교체 및 업데이트가 가능한 소프트웨어 단위인 컴포넌트로 구성된다.
• 비즈니스 중심 조직: 개발팀은 특정 기술이 아닌 비즈니스 기능 중심으로 구성된 기능 횡단형 팀(cross-functional team)으로 조직된다.
• 프로젝트가 아닌 프로덕트: 개발팀은 단순히 프로젝트를 완료하고 해산하는 것이 아니라, 제품의 전체 수명 주기에 걸쳐 책임을 진다.
• 스마트 엔드포인트와 덤 파이프: 서비스 간 통신은 가볍고 단순한 프로토콜(덤 파이프)을 사용하고, 로직 처리와 같은 기능은 각 서비스의 엔드포인트(스마트 엔드포인트)에서 담당한다.
• 분산 거버넌스: 중앙 집중적인 관리 대신, 각 서비스 팀이 자신들의 서비스에 맞는 기술 스택이나 표준을 자율적으로 선택한다.
• 분산 데이터 관리: 각 서비스는 자신만의 데이터 저장소를 관리하며, 다른 서비스와 데이터를 직접 공유하기보다는 API를 통해 통신한다.
• 인프라 자동화: 지속적 통합(CI) 및 지속적 전달(CD)을 포함한 인프라 관리를 자동화하여 빠르고 안정적인 배포를 지원한다.
• 장애 설계: 개별 서비스는 언제든지 실패할 수 있다는 가정하에, 시스템 전체의 안정성을 유지하기 위해 장애를 신속하게 감지하고 자동으로 복구할 수 있도록 설계한다.
• 진화적 설계: 시스템 전체를 한 번에 변경하는 대신, 각 서비스를 독립적으로 빈번하고 신속하게 변경, 폐기, 구축할 수 있도록 설계하여 시스템이 점진적으로 발전할 수 있게 한다.

5. 마이크로서비스 세분성

마이크로서비스 아키텍처에서 서비스의 적절한 크기, 즉 세분성을 결정하는 것은 간단하지 않으며, 보통 아키텍트와 개발자 간의 반복적인 논의와 협업을 통해 이루어진다. 이 과정에서는 사용자 요구사항, 각 서비스가 맡아야 할 책임 범위, 그리고 비기능적 요구사항(예: 성능, 보안, 안정성 등)과 같은 다양한 아키텍처적 특성을 신중하게 평가해야 한다.

소프트웨어 아키텍트인 닐 포드(Neal Ford^eng)는 서비스 세분성을 결정할 때 통합 인자와 분리 인자를 고려하는 것이 중요하다고 강조한다.

• 통합 인자: 여러 서비스가 하나의 트랜잭션을 공유해야 하거나, 프로세스가 서로 매우 밀접하게 연결되어 있는 경우처럼 서비스를 하나로 묶는 것이 유리한 요인을 말한다.
• 분리 인자: 특정 서비스의 장애가 다른 서비스에 영향을 미치지 않도록 하는 내결함성을 높이거나, 특정 기능만 독립적으로 확장해야 하는 필요성처럼 운영 및 아키텍처 목표를 달성하기 위해 서비스를 나누는 것이 유리한 요인을 의미한다.

• '''컴포넌트 경계 설정의 어려움:''' 서비스를 나누는 기준(경계)을 정하기 어렵다. 일반적으로는 서비스를 배포하고 변경하는 단위가 경계가 되지만, 이는 비즈니스 상황이나 시장 변화에 따라 달라질 수 있다.
• '''인터페이스 변경의 복잡성:''' 서비스 간의 인터페이스가 변경될 경우, 관련된 모든 서비스에 걸쳐 수정하기가 어렵다. 변경 사항을 관련 팀들과 조율해야 하고, 이전 버전과의 호환성을 유지하기 위한 추가 작업이 필요하며, 테스트 과정도 더 복잡해진다.
• '''복잡성의 이동:''' 컴포넌트 설계가 잘못되면, 기존에 컴포넌트 내부에 있던 복잡한 연결 구조가 여러 컴포넌트 사이의 통신 문제로 옮겨가면서 오히려 전체 시스템의 복잡성이 더 커질 위험이 있다.
• '''팀 역량의 중요성:''' 마이크로서비스는 숙련된 개발팀에게는 매우 효과적일 수 있지만, 경험이 부족한 팀이 다룰 경우 문제가 발생하기 쉽고, 특정 서비스의 문제가 시스템 전체에 영향을 미칠 수 있다.

6. 경계 컨텍스트 매핑

도메인 주도 설계(DDD)의 기본 개념인 경계 컨텍스트는 도메인 모델이 일관되고 유효한 특정 영역을 정의하여 관심사의 명확성과 분리를 보장한다.^[13] 마이크로서비스 아키텍처에서 경계 컨텍스트는 종종 마이크로서비스에 매핑되지만, 이 관계는 설계 접근 방식에 따라 다를 수 있다.

각 경계 컨텍스트가 단일 마이크로서비스로 구현되는 일대일(1:1) 관계는 명확한 경계를 유지하고, 결합도를 줄이며, 독립적인 배포 및 확장을 가능하게 하므로 일반적으로 이상적으로 여겨진다.

그러나 다른 매핑 방식도 상황에 따라 적절할 수 있다.

• 일대다(1:N) 관계: 하나의 경계 컨텍스트가 다양한 확장성이나 다른 운영 요구 사항을 해결하기 위해 여러 마이크로서비스로 분할되는 경우이다.
• 다대일(N:1) 관계: 단순성을 추구하거나 운영 오버헤드를 최소화하기 위해 여러 경계 컨텍스트를 단일 마이크로서비스로 통합하는 경우이다.

7. 장점

마이크로서비스 아키텍처는 애플리케이션을 여러 개의 독립적인 서비스로 분해함으로써 다양한 이점을 제공한다.

• 모듈성: 애플리케이션을 여러 개의 작은 서비스로 나누어 모듈성을 높인다.^[64] 이를 통해 전체 시스템을 더 쉽게 이해하고 개발하며 테스트할 수 있게 된다. 또한, 시스템 구조가 시간이 지나면서 의도치 않게 변형되는 현상(아키텍처 침식)에 대한 복원력을 높인다.^[15] 이는 복잡성이 높은 모놀리식 아키텍처와 비교했을 때 두드러지는 장점이다.^[16]

• 확장성: 각 마이크로서비스는 서로 독립적으로 구현되고 배포되므로, 필요에 따라 특정 서비스만 개별적으로 모니터링하고 확장하는 것이 가능하다.^{[17][70][71][72]} 예를 들어, 애플리케이션의 특정 기능에만 사용량이 집중될 경우, 모놀리식 아키텍처에서는 전체 애플리케이션을 확장해야 하지만^[6], 마이크로서비스 아키텍처에서는 해당 기능과 관련된 서비스만 선택적으로 확장하면 된다. 이는 자원 사용 및 비용 측면에서 효율성을 제공한다.^[7]

• 이질적인 시스템 및 레거시 시스템과의 통합: 마이크로서비스는 서로 다른 기술 스택으로 구성된 시스템이나 오래된 레거시 시스템과의 통합을 용이하게 한다. 기존의 거대한 모놀리식 아키텍처로 구축된 애플리케이션을 현대화하는 효과적인 방법으로 여겨지며^[18][19], 실제로 많은 기업들이 기존 시스템의 일부 기능을 마이크로서비스로 점진적으로 대체하거나 소프트웨어 현대화를 진행하고 있다.^[20][21]

• 분산 개발: 여러 개의 소규모 자율 팀이 각각의 서비스를 독립적으로 개발하고 배포, 확장할 수 있게 하여 개발 과정을 병렬화하고 속도를 높인다.^[22] 각 팀은 담당 서비스에 대한 오너십을 가지고 지속적인 리팩토링을 통해 서비스 구조를 개선해 나갈 수 있다.^[23] 또한, 서비스별로 독립적인 배포가 가능하므로^[68][59], 애플리케이션의 일부 기능 변경 시 해당 서비스만 다시 빌드하고 배포하면 되어 지속적 통합, 지속적 전달, 지속적 배포와 같은 민첩한 개발 프로세스를 적용하기에 유리하다.^[24][64][59]

8. 비판 및 문제점

마이크로서비스 접근 방식은 여러 비판에 직면하며 다음과 같은 문제점을 안고 있다.

• 정보 장벽: 서비스 간 정보 공유가 어려워 정보의 장벽이 형성될 수 있다.^[79][25]
• 네트워크 호출 비용 증가: 서비스 간 통신은 모놀리식 구조 내부의 함수 호출과 비교했을 때, 네트워크 지연 시간 및 메시지 처리 시간으로 인해 비용이 더 많이 든다.^[64][26] 이는 특히 서비스 간 호출이 잦을 경우 전체 시스템 성능에 영향을 줄 수 있다.
• 테스트 및 배포의 복잡성 증가: 여러 서비스가 독립적으로 움직이므로 테스트와 배포 과정이 더 복잡해진다.^[80][27] 특정 기능 변경이 여러 서비스에 걸쳐 있을 경우, 통합 테스트 및 배포 전략 수립이 어려워진다.
• 책임 이동의 어려움: 서비스 간의 책임 소재를 변경하는 것이 어렵다.^[59][25] 이는 서로 다른 팀 간의 소통, 다른 언어로 기능을 다시 작성하거나 다른 인프라스트럭처에 맞춰야 하는 작업을 포함할 수 있다.^[64][25]
• 과도한 서비스 분할 가능성: 서비스의 크기 자체에만 집중하면, 내부 모듈화가 더 효율적일 수 있는 상황에서도 불필요하게 많은 서비스를 만들게 될 수 있다.^[81][28] 이는 전체 아키텍처와 구성 요소 간 상호 의존성에 대한 이해를 필요로 한다.^[28]
• 분산 시스템 자체의 복잡성: 분산 시스템의 고유한 문제점들이 발생한다. 지연 시간, 메시지 형식 설계,^[32] 백업/가용성/일관성 (BAC),^[33] 부하 분산 및 결함 허용^[34] 등 관리해야 할 요소가 늘어난다. 모놀리식 애플리케이션의 복잡성이 단순히 사라지는 것이 아니라 운영상의 복잡성으로 전환되는 측면이 있다.^[35] 또한 네트워크 트래픽 증가로 인한 성능 저하, 관리해야 할 인터페이스 증가 등 아키텍처 복잡성이 커진다.^[36]
• 트랜잭션 처리의 어려움: 여러 서비스에 걸친 트랜잭션의 원자성을 보장하기 어렵다. 2단계 커밋 프로토콜은 서비스 간 강한 결합을 유발하여 마이크로서비스 철학에 맞지 않는 안티패턴으로 여겨지기도 하지만,^[29] 이를 사용하지 않으면 데이터 일관성을 유지하기 위한 별도의 복잡한 구현(예: 사가 패턴)이 필요하다.^[29]
• 데이터 집계의 어려움: 여러 마이크로서비스에 분산된 데이터를 모아 전체적인 관점에서 분석하거나 보고서를 작성하기 어렵다. 데이터를 추출하여 통합된 형식(스키마)으로 집계하는 과정이 필요하다.
• 기술 다양성으로 인한 관리 부담: 각 서비스가 서로 다른 프로그래밍 언어, 데이터베이스, 기술 스택을 사용할 수 있어 개발 및 운영, 유지보수가 더 어려워질 수 있다. 특히 개발자가 여러 프로젝트를 오가는 경우 부담이 커진다.^[30]
• 내부 통신 프로토콜의 비효율성: 주로 사용되는 HTTP 프로토콜은 외부 공개 서비스에 적합하게 설계되어, 높은 신뢰성이 요구되는 내부 서비스 간 통신에는 비효율적이거나 부적합할 수 있다.^[31]
• 기능 중심 분해의 한계: 서비스를 기능 중심으로만 분해할 경우, 요구사항 변경에 유연하게 대처하기 어렵고 오히려 서비스 복잡성만 증가시킬 수 있다.^[31]
• 개념의 모호성: '마이크로' 서비스의 기준이 명확하지 않아, 언제부터 또는 어디까지를 마이크로서비스로 볼 것인지에 대한 정의가 부족하다.^[31]
• 인터페이스 변경의 어려움: 서비스 간의 인터페이스가 변경될 경우 관련된 모든 서비스에 영향을 미치므로 변경 작업이 복잡하다. 하위 호환성을 유지하기 위한 추가 작업이 필요하며, 테스트 역시 복잡해진다.^[45]
• 복잡성 전이 위험: 서비스(컴포넌트)가 잘못 설계되면, 내부의 복잡성이 서비스 간의 연결 관계로 이동하여 전체 시스템의 복잡성을 오히려 증가시킬 위험이 있다.^[45]
• 높은 수준의 팀 기술 요구: 마이크로서비스 아키텍처를 효과적으로 운영하기 위해서는 개발팀과 운영팀의 높은 기술 수준이 요구된다. 기술 수준이 낮은 팀에서는 오히려 문제가 발생할 수 있다.^[45]

9. 안티패턴

마크 리처즈(Mark Richards)가 지적한 몇 가지 주요 안티패턴과 마이크로서비스 도입 시 고려해야 할 과제들은 다음과 같다.

• '''데이터 중심 마이그레이션 안티패턴''': 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 전환할 때, 데이터 마이그레이션을 우선 처리하는 방식의 어려움을 말한다. 이를 해결하기 위해서는 애플리케이션 코드를 먼저 마이그레이션하고, 새로운 마이크로서비스가 임시로 기존 모놀리식 데이터베이스를 사용하도록 하는 반복적인 접근 방식이 도움이 될 수 있다. 시간이 지나면서 시스템에 대한 이해도가 높아지면 데이터를 점진적으로 분리하고 재구성하여 각 마이크로서비스가 자체 데이터베이스를 갖도록 할 수 있다. 이 전략은 마이그레이션 과정을 단순화하고 데이터 관련 오류를 줄이는 데 기여한다.^[37]

• '''타임아웃 안티패턴''': 분산 시스템 환경에서 적절한 타임아웃(timeout) 값을 설정하는 것의 어려움을 설명한다. 타임아웃을 너무 짧게 설정하면 정상적인 요청이 실패 처리될 수 있고, 이를 해결하기 위해 복잡한 로직이 추가될 수 있다. 반대로 타임아웃을 너무 길게 설정하면 오류 발생 시 응답이 늦어져 사용자 경험이 저하될 수 있다. 회로 차단기 패턴은 하트비트(heartbeat), "합성 트랜잭션"(synthetic transaction), 실시간 사용량 모니터링 등을 통해 서비스 상태를 지속적으로 확인하여 이러한 문제를 완화할 수 있다. 이를 통해 오류를 더 빠르게 감지하고 분산 아키텍처 환경에서 전반적인 사용자 경험을 개선할 수 있다.^[37]

• '''공통화 기반 및 컴포넌트 경계 설정의 어려움''': 서비스를 어떤 단위로 나누어 릴리스하고 변경할지 결정하는 것이 어렵다. 이 경계는 비즈니스 상황이나 시장 변화에 따라 달라질 수 있다.
• '''인터페이스 변경에 따른 리팩터링 복잡성''': 서비스 경계를 넘나드는 변경 작업이 어렵다. 여러 서비스 간에 인터페이스 변경을 조율해야 하며, 하위 버전과의 호환성을 유지하기 위한 추가 작업이 필요하고 테스트 과정도 더 복잡해진다.
• '''컴포넌트 구성의 복잡성 증가''': 컴포넌트가 잘못 구성되면, 내부 복잡성이 컴포넌트 간의 연결 문제로 전이되어 시스템 전체에 더 큰 영향을 미칠 위험이 있다.
• '''팀 역량 의존성''': 마이크로서비스는 높은 기술 역량을 가진 팀에게 효과적이지만, 그렇지 않은 팀에서는 제대로 작동하지 않을 수 있다. 특정 마이크로서비스의 문제가 시스템 전체로 확산될 가능성이 있다.

10. 모범 사례

오라일리에 따르면, 각 마이크로서비스는 자체적인 아키텍처적 특성(일명 비기능 요구사항)을 가져야 하며, 아키텍트는 전체 분산 컴퓨팅 시스템에 대해 획일적인 특성을 정의해서는 안 된다.^[11]

2014년 당시 옹호자들은 마이크로서비스가 소프트웨어 아키텍처의 미래 방향이라고 확신하지는 않는다고 언급했다.

접근 방식 중 하나는 마이크로서비스 아키텍처로 처음부터 시작하지 않는 것이다. 대신 모놀리스로 시작하여 모듈화된 상태를 유지하고, 모놀리스가 문제가 되면 마이크로서비스로 이전하거나 분할해 나가는 방식이다.

11. 기술

마이크로서비스는 다양한 프로그래밍 언어로 구현할 수 있으며, 각기 다른 인프라스트럭처를 사용할 수 있다.^[78][38] 이러한 유연성 때문에 마이크로서비스 아키텍처에서는 개별 서비스가 서로 어떻게 통신하는지가 매우 중요한 기술적 고려 사항이 된다.^[78][38]

서비스 간 통신 방식은 크게 동기(Synchronous), 비동기(Asynchronous), UI 통합(UI Integration) 방식으로 나눌 수 있다.^[78][38] 통신에 사용되는 주요 프로토콜로는 RESTful HTTP, 메시징, GraphQL 등이 있다.^[38] 전통적인 모놀리식 시스템에서는 특정 기술(예: 프로그래밍 언어) 선택이 시스템 전체에 영향을 미치지만, 마이크로서비스에서는 각 서비스에 최적화된 기술을 독립적으로 선택할 수 있다는 점에서 접근 방식이 다르다.^[78][38]

한편, 이클립스 재단은 마이크로서비스 개발을 돕기 위한 사양으로 이클립스 마이크로프로파일(Eclipse MicroProfile)을 발표하기도 했다.^[39][40]

12. 서비스 메시

'''서비스 메시'''('''Service Mesh''')는 애플리케이션을 구성하는 마이크로서비스 집합으로 구성된 네트워크이다.^[54] 마이크로서비스 간 통신을 사용하여 애플리케이션을 구성하려면 데이터 전송을 제어하고 감시하는 것이 필수적이다. 서비스 메시는 이러한 네트워크 관련 기능을 애플리케이션에서 분리하여 마이크로서비스 구현을 용이하게 한다.

서비스 메시에서 각 서비스 인스턴스는 서비스 프록시, 사이드카 프록시 또는 사이드카라고 불리는 리버스 프록시 서버 인스턴스와 함께 배치된다. 서비스 인스턴스와 사이드카 프록시는 컨테이너를 공유하며, 이 컨테이너는 쿠버네티스, 노마드, 도커 스웜, 또는 DC/OS와 같은 컨테이너 오케스트레이션 도구를 통해 관리된다. 서비스 프록시는 다른 서비스 인스턴스와의 통신을 담당하며 다음과 같은 기능을 제공한다.^[55]

• 서비스 디스커버리
• 부하 분산
• 장애 복구
• 메트릭
• 감시
• 인증 및 권한 부여
• 보안 통신

• '''Envoy''': 서비스 메시 환경에서 데이터 플레인 프록시로 사용된다.^[57] Envoy 프록시는 각 마이크로서비스와 함께 사이드카 형태로 배포되어, Envoy 프록시 간 통신을 통해 서비스 메시를 구성한다. 마이크로서비스는 동봉되는 Envoy 프록시만을 보고 있기 때문에 서비스 메시가 투명하게 처리된다(숨겨져 있다). Envoy 데이터 플레인이 이용하는 제어 정보는 별도로 준비된 컨트롤 플레인에서 제공된다(예: 정적 설정 파일 또는 Istio와 같은 컨트롤 플레인 서비스).
• '''Istio''': Envoy를 데이터 플레인으로 사용하는 대표적인 오픈 소스 컨트롤 플레인이다.
• '''AWS App Mesh''': 아마존 웹 서비스(AWS)에서 제공하는 관리형 서비스 메시이다. Envoy를 데이터 플레인으로 한 관리형 컨트롤 플레인을 제공한다.^[58]

참조

_[1] 서적 Patterns of Enterprise Application Architecture Addison-Wesley Professional
_[2] 서적 Building Microservices O'Reilly Media 2015-02-20
_[3] 서적 Microservices: Flexible Software Architectures Addison-Wesley 2016-10-12
_[4] 간행물 Microservice Architecture: Aligning Principles, Practices, and Culture O'Reilly 2016
_[5] 웹사이트 Microservice Prerequisites https://martinfowler[...] 2014-08-28
_[6] 서적 Microservice Patterns Manning Publications 2018-11
_[7] 학술지 Developing Self-Adaptive Microservice Systems: Challenges and Directions 2019-10-16
_[8] 웹사이트 Cloud Microservices Market 2020 Trends, Market Share, Industry Size, Opportunities, Analysis and Forecast by 2026 – Instant Tech Market News https://www.instantt[...] 2020-02-18
_[9] 웹사이트 Architecture and Design of an XML Application Platform http://www.hpl.hp.co[...] 2004
_[10] 웹사이트 Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity http://www.cloudcomp[...] SYS-CON Media 2005-02-15
_[11] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
_[12] 서적 Building Evolutionary Architectures: Support Constant Change O'Reilly Media
_[13] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
_[14] 서적 Building Microservices by Sam Newman
_[15] 학회 Microservices: Architecting for Continuous Delivery and DevOps https://www.research[...] IEEE 2018
_[16] 학술지 Microservices 2016
_[17] 서적 Perspectives of System Informatics 2017
_[18] 서적 Building Microservices O'Reilly 2015
_[19] 서적 Microservices: Flexible Software Architecture Addison Wesley 2016
_[20] 학술지 Drivers and Barriers for Microservice Adoption – A Survey among Professionals in Germany https://www.research[...] 2019
_[21] 학술지 Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages https://www.research[...] 2017
_[22] 웹사이트 Microservice architecture pattern http://microservices[...] 2017-03-19
_[23] 학회 Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development IEEE 2014
_[24] 학술지 Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture http://spiral.imperi[...] 2016-05
_[25] 웹사이트 Experiences from Failing with Microservices http://www.infoq.com[...] 2014-08-11
_[26] 웹사이트 Microservices http://martinfowler.[...]
_[27] 웹사이트 Why unit testing is not enough when it comes to microservices https://medium.com/s[...] 2021-04-07
_[28] 학술지 Understanding Software Evolution using a Combination of Software Visualization and Software Metrics https://rmod.inria.f[...] 2002
_[29] 서적 Microservice Patterns Manning Publications 2018-11
_[30] Youtube 10 Tips for failing badly at Microservices by David Schmitz https://www.youtube.[...] 2017-08-30
_[31] 서적 Righting Software 1st ed. Addison-Wesley Professional
_[32] 학술지 Microservices in Practice, Part 2: Service Integration and Sustainability
_[33] 학술지 Consistent Disaster Recovery for Microservices: the BAC Theorem
_[34] 웹사이트 Developing Microservices for PaaS with Spring and Cloud Foundry http://www.infoq.com[...]
_[35] 웹사이트 Microservice Trade-Offs https://www.martinfo[...]
_[36] 뉴스 BRASS Building Resource Adaptive Software Systems U.S. Government 2015-04-07
_[37] 서적 Microservices AntiPatterns and Pitfalls O'Reilly
_[38] 서적 Microservices - A Practical Guide http://practical-mic[...] CreateSpace Independent Publishing Platform 2018-04-15
_[39] 웹사이트 Eclipse MicroProfile https://projects.ecl[...] 2016-12-14
_[40] 웹사이트 MicroProfile https://microprofile[...] 2021-04-11
_[41] 컨퍼런스 Microservices: Architecting for Continuous Delivery and DevOps https://www.research[...] IEEE 2018
_[42] 웹사이트 Microservice architecture pattern http://microservices[...] 2017-03-19
_[43] 컨퍼런스 Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development IEEE 2014
_[44] 저널 Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture 2016-05
_[45] 웹사이트 Microservices https://martinfowler[...] martinfowler.com 2018-12-06
_[46] 웹사이트 Microservices http://martinfowler.[...] 2018-01-02
_[47] 서적 Building Microservices O'Reilly Media 2015-02-20
_[48] 서적 Microservices: Flexible Software Architectures http://microservices[...] 2016-10-12
_[49] 웹사이트 Micro-services for performance https://vanilla-java[...] 2016-03-22
_[50] 문서 Microservice Architecture: Aligning Principles, Practices, and Culture O’Reilly 2016
_[51] 컨퍼런스 Microservices: Architecting for Continuous Delivery and DevOps https://www.research[...] IEEE 2018
_[52] 웹사이트 Backends For Frontends Pattern https://docs.microso[...] Microsoft 2018-01-02
_[53] 서적 Microservices: Patterns and Applications
_[54] 문서 Istio - Docs - What is Istio https://istio.io/doc[...]
_[55] 문서 Istio - Docs - What is Istio https://istio.io/doc[...]
_[56] 문서 Istio - Docs - What is Istio https://istio.io/doc[...]
_[57] 문서 Service mesh data plane vs. control plane https://blog.envoypr[...] 2017
_[58] 문서 Learning AWS App Mesh https://aws.amazon.c[...] 2019
_[59] 컨퍼런스 Microservices: Architecting for Continuous Delivery and DevOps https://www.research[...] IEEE 2018
_[60] 웹인용 Microservice architecture pattern http://microservices[...] 2017-03-19
_[61] 컨퍼런스 Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development https://dx.doi.org/1[...] IEEE 2014
_[62] 웹인용 Microservices-based architectures enable continuous delivery/deployment https://blog.eventua[...] 2017-03-19
_[63] 저널 Microservices: yesterday, today, and tomorrow https://arxiv.org/pd[...] 2017-05-02
_[64] 웹인용 Microservices http://martinfowler.[...]
_[65] 서적 Building Microservices https://archive.org/[...] O'Reilly Media
_[66] 서적 Microservices: Flexible Software Architectures http://microservices[...]
_[67] 웹인용 Micro-services for performance https://vanilla-java[...] 2017-03-19
_[68] 문서 Microservice Architecture: Aligning Principles, Practices, and Culture O’Reilly 2016
_[69] 웹인용 IFS: Microservices Resources and Positions https://www.ifs.hsr.[...] 2016-12-28
_[70] 저널 Microservices: Migration of a Mission Critical System https://arxiv.org/pd[...] 2017-05-02
_[71] 논문 Microservices: How To Make Your Application Scale https://arxiv.org/pd[...] 2017-05-02
_[72] 논문 Microservices Science and Engineering https://arxiv.org/pd[...] 2017-11-14
_[73] 웹인용 Microservices http://martinfowler.[...]
_[74] 서적 Microservices: Patterns and Applications
_[75] 웹인용 Philosophy of Microservices? http://microservices[...] 2018-09-27
_[76] 웹인용 Microservices: Five Architectural Constraints http://nirmata.com/2[...] 2018-09-27
_[77] 웹인용 Microservices Essentials for Executives: The Key to High Velocity Software Development https://www.datawire[...] Datawire, Inc. 2016-10-21
_[78] 서적 Microservices - A Practical Guide http://practical-mic[...]
_[79] 웹인용 Experiences from Failing with Microservices http://www.infoq.com[...] 2014-08-11
_[80] 웹인용 Developing Microservices for PaaS with Spring and Cloud Foundry http://www.infoq.com[...]
_[81] 웹인용 How small should your microservice be? https://www.innoq.co[...] 2014-11-17