애플리케이션 빌드에 마이크로 서비스 접근 방식을 사용하는 이유
소프트웨어 개발자의 경우 애플리케이션을 구성 요소 파트로 팩터링하는 것은 새로운 것이 아닙니다. 일반적으로 백 엔드 저장소, 중간 계층 비즈니스 논리 및 프런트 엔드 UI(사용자 인터페이스)와 함께 계층화된 접근 방식이 사용됩니다. 지난 몇 년 동안 겪은 변화는 개발자가 클라우드용 분산 애플리케이션을 빌드하고 있다는 것입니다.
다음은 변화하는 비즈니스 요구 사항입니다.
- 새로운 지역의 고객에 도달하기 위해 대규모로 빌드되고 운영되는 서비스가 필요합니다.
- 고객의 요구에 민첩하게 대처하도록 기능과 특징을 더 빠르게 전달해야 합니다.
- 리소스 사용률 향상으로 비용을 줄여야 합니다.
이러한 비즈니스 요구가 애플리케이션을 구축하는 방식 에 영향을 미칩니다.
마이크로 서비스에 대한 Azure 접근 방식에 대한 자세한 내용은 마이크로 서비스: 클라우드가 제공하는 애플리케이션 혁명을 참조하세요.
모놀리식과 마이크로 서비스 설계 방법 비교
모든 애플리케이션은 시간에 따라 진화합니다. 성공적인 애플리케이션은 사람들에게 유용하게 되어 진화합니다. 실패한 애플리케이션은 발전하지 않으며 결국 사용되지 않습니다. 문제는 현재의 요구 사항에 대해 얼마나 알고 있으며 그러한 요구 사항이 향후 어떻게 될 것인가입니다. 예를 들어 회사의 한 부서에 대한 보고 애플리케이션을 빌드하고 있다고 가정해 보겠습니다. 애플리케이션이 회사의 범위 내에만 적용되고 보고서는 오래 보관되지 않습니다. 수천만의 고객에게 비디오 콘텐츠를 제공하는 서비스를 구축하는 것과는 다른 방식으로 접근해야 합니다.
때로는 개념 증명으로 무언가를 꺼내는 것이 추진 요인이 됩니다. 나중에 애플리케이션을 다시 설계할 수 있다는 것을 알고 있습니다. 사용되지 않는 작업을 과도하게 엔지니어링하는 것은 별 의미가 없습니다. 반면 회사에서 클라우드를 구축할 때 기대하는 것은 성장과 사용입니다. 성장 및 규모는 예측할 수 없습니다. 신속하게 프로토타입화할 수 있는 동시에 미래의 성공을 위해 대비할 수 있기를 바라게 됩니다. 이것이 구축, 측정, 학습, 반복으로 이루어진 간결한 시작 접근 방식입니다.
클라이언트-서버 시절에는 각 계층마다 특정한 기술을 활용하여 계층화된 애플리케이션을 구축하는 데 주력하는 경향이 있었습니다. 이러한 접근 방식을 설명하는 데 모놀리식 애플리케이션이라는 용어가 부상했습니다. 인터페이스가 계층 사이에 속하는 경향이 있기 때문에 각 계층 내의 구성 요소 사이에는 더 긴밀히 연결된 설계가 적용되었습니다. 개발자들은 라이브러리에 컴파일되고 몇 개의 실행 파일과 DLL로 연결된 클래스를 설계하고 팩터링했습니다.
모놀리식 설계 접근 방식의 이점이 있습니다. 이러한 호출은 IPC(프로세스 간 통신)를 통해 자주 이루어지기 때문에 모놀리식 애플리케이션은 더 간단하게 설계할 수 있고 구성 요소 간의 호출이 더 빠릅니다. 또한 모든 사람이 단일 제품을 테스트하므로 인적 자원을 보다 효율적으로 사용하는 경향이 있습니다. 단점은 계층화된 레이어 사이가 단단히 결합되어 있기 때문에 개별 구성 요소를 확장할 수 없다는 점입니다. 즉, 수정이나 업그레이드가 필요할 때 다른 개발자가 테스트를 마칠 때까지 기다려야 합니다. 민첩하기가 더 어렵습니다.
마이크로 서비스는 이러한 단점을 해결하고 이전의 비즈니스 요구 사항과 보다 밀접하게 연결되어 있습니다. 그러나 여기에도 장단점이 있습니다. 마이크로 서비스의 장점은 일반적으로 각각이 더 간단한 비즈니스 기능을 캡슐화하며 독립적으로 스케일 아웃 또는 인, 테스트, 배포 및 관리할 수 있다는 점입니다. 마이크로 서비스 접근 방식의 한 가지 중요한 이점은 팀이 기술보다는 비즈니스 시나리오에 더 초점을 맞추게 된다는 것입니다. 더 적은 규모의 팀이 고객 시나리오를 기반으로 마이크로 서비스를 개발하고 원하는 기술을 사용합니다.
다시 말해 조직에서는 마이크로 서비스 애플리케이션을 유지하기 위해 기술을 표준화할 필요가 없습니다. 자체 서비스를 보유한 개별 팀은 팀의 전문 지식을 바탕으로 합리적이거나 문제 해결에 가장 적합한 것을 수행할 수 있습니다. 실제로 특정 NoSQL 스토어나 웹 애플리케이션 프레임워크 등 일련의 권장 기술이 선호됩니다.
마이크로 서비스의 단점은 더 많은 개별 엔터티를 관리하고 더 복잡한 배포 및 버전 관리를 처리해야 한다는 것입니다. 마이크로 서비스 간의 네트워크 트래픽은 해당 네트워크 대기 시간과 마찬가지로 늘어납니다. 번잡하고 세분화된 서비스가 많으면 성능 문제가 저하될 수 있습니다. 이러한 종속성을 확인하는 데 도움이 되는 도구가 없는 경우 전체 시스템을 확인하는 것은 어렵습니다.
표준은 통신 방법을 지정하고 엄격한 계약보다는 서비스에서 필요한 것에 대해서만 용인하여 마이크로 서비스 접근 방식을 작동하게 합니다. 서비스는 서로 독립적으로 업데이트되므로 설계 과정의 처음부터 계약을 정의하는 것이 중요합니다. 마이크로 서비스 접근 방식을 통한 설계와 연결된 또 다른 설명은 "세분화된 서비스 지향 아키텍처(SOA)"입니다.
마이크로 서비스 설계 접근 방식을 가장 간단하게 말하자면 각각 및 협의된 통신 표준에 대한 독립적인 변경을 통해 서비스의 페더레이션을 분리하는 것입니다.
점점 더 많은 클라우드 애플리케이션이 제작되면서 전체 애플리케이션을 이렇게 독립적인 시나리오 중심적 서비스로 해체하는 것이 더 장기적인 접근 방식이라는 점을 사람들이 알게 되었습니다.
애플리케이션 개발 접근 방식 비교
모놀리식 애플리케이션은 도메인 특정 기능을 포함하며 일반적으로 웹, 비즈니스, 데이터 등의 기능 계층으로 구분됩니다.
모놀리식 애플리케이션은 여러 서버/가상 머신/컨테이너에 복제하여 크기를 조정합니다.
마이크로 서비스 애플리케이션은 기능을 더 작은 개별 서비스로 구분합니다.
마이크로 서비스 접근 방식에서는 각 서비스를 독립적으로 배포하여 확장하며 서버/가상 머신/컨테이너 간에 이러한 서비스의 인스턴스를 만듭니다.
마이크로 서비스 접근 방식으로 설계하는 것이 모든 프로젝트에 적합한 것은 아니지만 앞서 설명한 비즈니스 목표와 더 밀접하게 일치합니다. 나중에 코드를 마이크로 서비스 설계로 다시 작업할 기회가 있다는 것을 알고 있다면 모놀리식 접근 방식으로 시작하는 것이 적합할 수 있습니다. 모놀리식 애플리케이션을 시작하고, 확장성 또는 민첩성이 더 필요한 기능 영역부터 천천히 단계별로 분할하는 것이 더 일반적입니다.
마이크로 서비스 접근 방식을 사용하는 경우 많은 소규모 서비스의 애플리케이션을 구성합니다. 이러한 서비스는 컴퓨터의 클러스터에 걸쳐 배포된 컨테이너에서 실행됩니다. 소규모 팀은 시나리오에 초점을 맞춘 서비스를 개발하고, 전체 애플리케이션이 발전할 수 있도록 각 서비스를 독립적으로 테스트, 버전 지정, 배포 및 크기를 조정합니다.
마이크로 서비스란?
마이크로 서비스에 대한 정의는 여러 가지가 있습니다. 하지만 마이크로 서비스의 이러한 특징은 대부분 널리 수락됩니다.
- 고객 또는 비즈니스 시나리오를 캡슐화합니다. 어떤 문제를 해결하고 있나요?
- 소규모 엔지니어링 팀에서 개발합니다.
- 임의 프로그래밍 언어로 작성되고 임의 프레임워크에 사용합니다.
- 개별적으로 버전 관리, 배포 및 확장되는 코드 및 상태(필요한 경우)로 구성됩니다.
- 잘 정의된 인터페이스와 프로토콜을 통해 타 마이크로 서비스와 상호 작용합니다.
- 자신의 위치를 확인하기 위해 사용하는 고유 이름(URL)이 있습니다.
- 일관되며 오류 시 사용 가능한 상태를 유지합니다.
요약하자면:
마이크로 서비스 애플리케이션은 독립적으로 버전 관리되며 확장성 있는 소규모 고객 중심 서비스로 구성됩니다. 이 서비스들은 잘 정의된 인터페이스가 있는 표준 프로토콜을 통해 서로 통신합니다.
임의 프로그래밍 언어로 작성되고 임의 프레임워크에 사용
개발자는 자신의 기술 및 Microsoft에서 만든 서비스 요구에 따라 프레임워크나 언어를 자유롭게 선택할 수 있어야 합니다. 어떤 서비스에서는 무엇보다도 C++의 성능 장점을 중시할 수 있습니다. 다른 사람들에게는 C# 또는 Java에서 얻는 관리 개발의 용이성이 더 중요할 수 있습니다. 일부 경우 특정 파트너 라이브러리, 데이터 스토리지 기술 또는 서비스를 클라이언트에 노출하는 방법을 사용해야 할 수 있습니다.
기술을 선택한 후에는 서비스의 운영 또는 수명주기 관리 및 크기 조정을 고려해야 합니다.
개별적으로 버전 관리, 배포 및 확장되는 코드와 상태 허용
마이크로 서비스를 어떻게 작성하든 코드 및 경우에 따라 상태에서 개별적으로 배포, 업그레이드 및 크기를 조정해야 합니다. 이 문제는 선택한 기술에 달려있기 때문에 해결하기 어렵습니다. 크기 조정을 위해 코드와 상태를 파티션(또는 분할)하는 방법을 이해하는 것은 어려운 일입니다. 현재 일반화된 코드 및 상태가 다양한 기술을 사용할 경우 마이크로 서비스의 배포 스크립트가 둘 다 크기 조정할 수 있어야 합니다. 이러한 분리는 민첩성과 유연성과도 관련이 있으므로 한 번에 모두 업그레이드하지 않고도 일부 마이크로 서비스를 업그레이드할 수 있습니다.
잠시 모놀리식 및 마이크로 서비스 접근 방식을 다시 비교해 보겠습니다. 이 다이어그램은 상태를 저장하는 방법의 차이점을 보여 줍니다.
두 접근 방식에 대한 상태 스토리지
왼쪽의 모놀리식 접근 방식에는 단일 데이터베이스와 특정 기술 계층이 있습니다.
오른쪽의 마이크로 서비스 접근 방식은 상호 연결된 마이크로 서비스의 그래프로, 일반적으로 상태가 마이크로 서비스로 보여지며 다양한 기술이 사용됩니다.
모놀리식 접근 방식에서 애플리케이션은 일반적으로 단일 데이터베이스를 사용합니다. 하나의 데이터베이스를 사용하는 경우의 장점은 단일 위치에 있기 때문에 쉽게 배포할 수 있다는 것입니다. 각 구성 요소에는 상태 저장을 위한 단일 테이블이 있습니다. 팀은 상태를 엄격히 구분해야 하지만, 이는 어려운 일입니다. 필연적으로 누군가 기존 고객 테이블에 열을 추가하고 테이블 간을 조인하며 스토리지 계층에서 종속성을 만들고자 합니다. 이러한 경우가 발생하면, 개별 구성 요소를 확장할 수 없습니다.
마이크로 서비스 접근 방식에서는 각 서비스가 자체 상태를 관리 및 저장합니다. 각 서비스는 서비스의 수요에 맞게 코드와 상태를 함께 확장해야 합니다. 이 경우에 애플리케이션 데이터의 뷰나 쿼리를 만들 때 여러 상태 저장소에 걸쳐 쿼리해야 한다는 단점이 있습니다. 이 문제는 일반적으로 마이크로 서비스 컬렉션에 대한 보기를 빌드하는 별도의 마이크로 서비스에 의해 해결됩니다. 데이터에 대해 여러 임시 쿼리를 실행해야 한다면 오프라인 분석을 위해 각 마이크로 서비스의 데이터를 데이터 웨어하우징 서비스에 기록해야 합니다.
마이크로 서비스는 버전이 지정됩니다. 여러 버전의 마이크로 서비스가 나란히 실행될 수 있습니다. 업그레이드하는 동안 최신 버전의 마이크로 서비스가 실패할 수 있으며 이전 버전으로 롤백해야 합니다. 버전 관리는 서로 다른 사용자가 서로 다른 서비스 버전을 경험하는 A/B 테스트에도 유용합니다. 예를 들어 새 기능을 더 널리 배포하기 전에 테스트를 위해 특정 고객 집단에서만 마이크로 서비스를 업그레이드하는 것이 일반적입니다.
잘 정의된 인터페이스와 프로토콜을 통해 타 마이크로 서비스와 상호 작용
지난 10년 동안 서비스 지향 아키텍처의 통신 패턴을 설명하는 광범위한 정보가 게시되었습니다. 일반적으로 서비스 통신은 직렬화 형식으로 HTTP 및 TCP 프로토콜과 XML 또는 JSON이 있는 REST 접근 방식을 사용합니다. 인터페이스 관점에서 웹 설계 접근 방식을 사용하는 것입니다. 그러나 이진 프로토콜이나 자체 데이터 형식을 사용하지 않을 이유는 없습니다. 이러한 프로토콜과 형식이 공개적으로 사용할 수 없는 경우 사용자는 마이크로 서비스를 사용하는 데 더 많은 시간을 소요할 수 있습니다.
자신의 위치를 확인하기 위해 사용하는 고유 이름(URL)이 있음
마이크로 서비스는 실행하는 모든 곳에서 주소 지정이 가능해야 합니다. 컴퓨터 및 특정 마이크로 서비스를 실행할 컴퓨터에 대해 고려하면 급격한 문제가 발생할 수 있습니다.
DNS가 특정 URL을 특정 머신으로 확인하는 것과 동일한 방법으로 마이크로 서비스는 현재 위치를 검색할 수 있는 고유의 이름이 필요합니다. 마이크로 서비스는 실행 중인 인프라와 독립적 관계인 주소 지정 가능한 이름이 필요합니다. 서비스 레지스트리가 있어야 하므로 이는 서비스가 배포된 방식과 확인되는 방식 간의 상호 작용이 있다는 것을 의미합니다. 컴퓨터가 실패하면 레지스트리 서비스는 서비스가 이동된 위치를 알려주어야 합니다.
일관되며 오류 시 사용 가능한 상태 유지
예기치 않은 오류를 처리하는 것은 특히 분산 시스템에서 해결하기 가장 어려운 문제 중 하나입니다. 개발자로서 작성하는 대부분의 코드는 예외를 처리하기 위한 것입니다. 테스트하는 동안 예외 처리에 가장 많은 시간이 소요됩니다. 프로세스는 오류를 처리하는 코드를 작성하는 것보다 조금 더 복잡합니다. 마이크로 서비스가 실행 중인 컴퓨터가 실패하는 경우 어떻게 되나요? 그 자체만으로 까다로운 문제인 오류를 탐지해야 합니다. 그러나 마이크로 서비스도 다시 시작해야 합니다.
가용성을 위해 마이크로 서비스는 오류를 복구하고 다른 컴퓨터에서 다시 시작할 수 있어야 합니다. 이러한 복원력 요구 사항 외에도 데이터가 손실되어서는 안 되며 데이터가 일관성을 유지해야 합니다.
애플리케이션 업그레이드 중에 오류가 발생하면 복원력을 얻기가 어렵습니다. 배포 시스템과 작업하는 마이크로 서비스는 복구할 필요가 없습니다. 새 버전으로의 이전을 계속하거나 일관적인 상태를 유지하기 위해 이전 버전으로 롤백할 수 있는지 결정해야 합니다. 계속 진행할 수 있는 충분한 컴퓨터가 있는지와 이전 버전의 마이크로 서비스를 복구하는 방법 등 몇 가지 질문을 고려해야 합니다. 이러한 결정을 내리기 위해 상태 정보를 내보내는 마이크로 서비스가 필요합니다.
보고서 상태 및 진단
당연하지만 자주 간과되는 것으로, 마이크로 서비스는 자신의 상태와 진단을 보고하는 것이 필수적입니다. 보고가 없으면 운영의 관점에서 상태에 대한 정보를 거의 얻을 수 없습니다. 일련의 독립적인 서비스를 통틀어 진단 이벤트 간의 상관 관계를 파악하고 이벤트 순서를 알기 위해 머신의 시간 차이를 이해하는 것은 어려운 작업입니다. 협의된 프로토콜과 데이터 형식을 통해 마이크로 서비스와 상호 작용하는 것과 같은 방식으로, 로그 상태와 진단 이벤트를 로깅하는 방법을 표준화해야 하며 이는 궁극적으로 쿼리 및 보기를 위한 이벤트 저장소로 귀결됩니다. 마이크로 서비스 접근 방식에서는 여러 팀이 단일 로깅 형식에 동의하는 것이 중요합니다. 애플리케이션에서 진단 이벤트를 전체적으로 보는 데 일관된 접근 방식이 필요합니다.
상태는 진단과 다릅니다. 상태는 적절한 조치를 취하도록 마이크로 서비스가 현재 상태를 보고하는 것입니다. 좋은 예로는 가용성을 유지하기 위해 업그레이드 및 배포 메커니즘을 사용하는 것입니다. 프로세스 충돌이나 컴퓨터 재부팅으로 서비스가 현재 정상 상태가 아니더라도 계속 운영될 수 있습니다. 업그레이드를 시작하여 상황을 악화시키는 일은 지양해야 합니다. 먼저 조사하거나 마이크로 서비스가 복구할 시간을 주는 것이 최선입니다. 마이크로 서비스의 상태 이벤트를 통해 정보에 입각한 의사 결정을 내리고 효과적인 자체 복구 서비스를 만들 수 있습니다.
Azure에서 마이크로 서비스를 설계하기 위한 지침
Azure에서 마이크로 서비스 설계 및 빌드에 대한 지침을 보려면 Azure 아키텍처 센터를 방문하세요.
마이크로 서비스 플랫폼으로서의 서비스 패브릭
Azure Service Fabric은 Microsoft가 보통 모놀리식의 박스 제품을 제공하는 방식에서 서비스를 제공하는 방식으로 전환하는 과정에 등장했습니다. Azure SQL Database 및 Azure Cosmos DB와 같은 대규모 서비스를 빌드 및 운영한 경험을 기반으로 Service Fabric을 만들었습니다. 플랫폼은 시간이 지남에 따라 더 많은 서비스를 도입하는 방향으로 발전했습니다. Service Fabric이 Azure뿐 아니라 독립 실행형 Windows Server 배포에서 실행되어야 했다는 점입니다.
Service Fabric의 목표는 인프라 리소스의 효율적 사용 등, 서비스 빌드 및 실행의 난제를 해결하여 팀이 마이크로 서비스 접근 방식을 사용하여 비즈니스 문제를 해결할 수 있게 하는 것입니다.
Service Fabric은 마이크로 서비스 접근 방식을 사용하는 애플리케이션을 쉽게 빌드할 수 있도록 다음을 제공합니다.
- 실패한 서비스를 배포, 업그레이드, 검색 및 다시 시작하고 서비스를 검색하며 메시지를 라우팅하고 상태를 관리 및 모니터링하는 시스템 서비스를 제공하는 플랫폼입니다.
- 컨테이너에서 실행되거나 프로세스로 실행되는 애플리케이션을 배포하는 기능입니다. Service Fabric은 컨테이너 및 프로세스 조정자입니다.
- 마이크로 서비스로서 애플리케이션을 구축하는 데 도움이 되는 생산성 있는 프로그래밍 API: ASP.NET Core, Reliable Actors 및 Reliable Services. 예를 들어 상태 및 진단 정보를 받거나 기본 제공되는 고가용성을 활용할 수 있습니다.
Service Fabric은 서비스를 빌드한 방법에 구애받지 않으며 모든 기술을 사용할 수 있습니다. 그러나 마이크로 서비스를 보다 간편하게 빌드할 수 있는 기본 제공 프로그래밍 API를 제공합니다.
Service Fabric으로 기존 애플리케이션 마이그레이션
Service Fabric을 사용하면 기존 코드를 다시 사용하고 새로운 마이크로 서비스로 현대화할 수 있습니다. 애플리케이션을 현대화하는 데에는 5단계가 있으며 어느 단계에서든 시작 및 중지할 수 있습니다. 단계는 다음과 같습니다.
- 기존의 모놀리식 애플리케이션을 시작합니다.
- 마이그레이션. 컨테이너 또는 게스트 실행 파일을 사용하여 Service Fabric에서 기존 코드를 호스팅합니다.
- 현대화. 기존 컨테이너화된 코드와 함께 새 마이크로 서비스를 추가합니다.
- 혁신. 필요에 따라 모놀리식 애플리케이션을 마이크로 서비스로 나눕니다.
- 애플리케이션을 마이크로 서비스로 변환. 기존 모놀리식 애플리케이션을 변환하거나 새로운 그린필드 애플리케이션을 빌드합니다.
이러한 단계 중 어느 지점에서든 시작 및 중지할 수 있습니다. 다음 단계로 진행하지 않아도 됩니다.
각 단계에 대한 예를 살펴 보겠습니다.
마이그레이션
두 가지 이유로 많은 회사가 기존 모놀리식 애플리케이션을 컨테이너로 마이그레이션하고 있습니다.
- 기존 하드웨어의 통합 및 제거 또는 더 높은 밀도에서 애플리케이션 실행으로 인한 비용 절감
- 개발 및 운영 간의 일관된 배포 계약
비용 절감은 간단합니다. Microsoft에서 기존의 많은 애플리케이션을 컨테이너화하여 수백만 달러를 절감하고 있습니다. 일관된 배포는 평가하기 어렵지만 똑같이 중요합니다. 이는 개발자가 자신에게 적합한 기술을 선택할 수 있지만 작업에서는 애플리케이션을 배포하고 관리하기 위해 한 가지 방법만 수락한다는 것을 의미합니다. 개발자가 특정 기술만 선택하도록 강요하지 않고도 다양한 기술을 지원하는 복잡성을 처리해야 하는 작업에서 벗어날 수 있습니다. 기본적으로 모든 애플리케이션은 자체 포함된 배포 이미지에 컨테이너화됩니다.
대부분의 조직에서는 여기까지만 수행합니다. 컨테이너의 이점을 이미 얻었기 때문입니다. Service Fabric은 배포, 업그레이드, 버전 관리, 롤백 및 상태 모니터링을 비롯한 전체 관리 환경을 제공합니다.
현대화
현대화는 컨테이너화된 기존 코드와 함께 새로운 서비스를 추가하는 것입니다. 새 코드를 작성하려는 경우 마이크로 서비스 경로의 단계를 따르는 것이 좋습니다. 그러면 새 REST API 엔드포인트 또는 새로운 비즈니스 논리를 추가할 수 있습니다. 이러한 방식으로 새로운 마이크로 서비스 빌드 프로세스를 시작하고 개발 및 배포를 연습합니다.
혁신
마이크로 서비스 접근 방식은 변화하는 비즈니스 요구 사항을 수용합니다. 이 단계에서는 모놀리식 애플리케이션을 서비스로 분할할 것인지 아니면 혁신할 것인지 결정해야 합니다. 여기서 전형적인 예는 워크플로 큐로 사용 중인 데이터베이스가 병목 상태를 처리하게 되는 경우입니다. 워크플로 요청의 수가 증가하므로 작업은 크기에 따라 배포되야 합니다. 크기가 조정되지 않거나 더 자주 업데이트해야 하는 애플리케이션의 특정 부분을 마이크로 서비스로 분리하고 혁신합니다.
애플리케이션을 마이크로 서비스로 변환
이 단계에서 애플리케이션은 마이크로 서비스로 완전히 구성(또는 분할)됩니다. 이 지점에 도달하기 위해 마이크로 서비스 경험을 완료했습니다. 여기에서 시작할 수는 있지만 마이크로 서비스 플랫폼의 도움 없이 이 작업을 수행하려면 많은 투자가 필요합니다.
마이크로 서비스가 내 애플리케이션에 적합할까요?
아마도 그렇습니다. Microsoft에서 더 많은 팀이 비즈니스상의 이유로 클라우드를 빌드하기 시작함에 따라 많은 팀이 마이크로 서비스와 유사한 접근 방식을 취하는 장점을 인식하게 되었습니다. 예를 들어 Bing은 수년 전부터 마이크로 서비스를 사용해 왔습니다. 다른 팀의 경우 마이크로 서비스 접근 방식은 새로웠습니다. 팀은 핵심 역량이 아니면서 해결이 필요한 까다로운 문제를 찾았습니다. 이 때문에 Service Fabric이 서비스 빌드 기술로 주목을 받고 있습니다.
Service Fabric의 목표는 많은 비용이 소모되는 재설계를 피할 수 있도록 마이크로 서비스 애플리케이션 빌드의 복잡성을 줄이는 것입니다. 처음에는 소규모로 시작해서 고객의 사용량에 따라 확장하고, 서비스를 중단하고, 새 서비스를 추가하고, 발전해 가는 것이 바로 이 접근 방식입니다. 대부분의 개발자들이 더 쉽게 마이크로 서비스에 접근할 수 있게 하기 위해서는 아직 많은 문제들을 해결해야 한다는 점도 알고 있습니다. 컨테이너와 작업자 프로그래밍 모델은 이 방향으로 나아가기 위한 예입니다. 마이크로 서비스 접근 방식을 더 쉽게 만들기 위해 더 많은 혁신이 나타날 것이라고 확신합니다.