SaaS로의 여정: Dynamics 365

많은 ISV(독립 소프트웨어 공급업체)는 온-프레미스 소프트웨어 배달에서 클라우드 기반 및 SaaS(Software-as-a-Service) 기반 배달 모델로 전환하는 것에 대해 생각합니다. Microsoft에서는 많은 제품과 함께 이 여정을 거쳤으며, 실제 경험과 그 과정에서 배운 주요 교훈을 공유하라는 요청을 받았습니다.

이 문서의 목표는 Microsoft Dynamics 365를 빌드할 때 이 여정이 어떻게 진행되었는지에 대한 개요를 제공하는 것입니다. 우리는 우리가 겪은 사고 과정과 우리가 내린 각 주요 결정에 대한 핵심 동인을 설명합니다. 이 문서에서는 온-프레미스 소프트웨어를 제공하는 것에서 수천 개의 조직에서 수백만 명의 사용자가 사용하는 하이퍼스케일 SaaS 제품으로 전환하면서 제품의 진화를 이해하기를 바랍니다. 이 문서를 읽으면 경험을 통해 배우고 SaaS로의 여정을 계획할 수 있기를 바랍니다. Dynamics 365를 사용한 Microsoft의 여정은 고유할 수 있지만, 우리가 배운 교훈과 원칙은 SaaS 모델로의 전환을 계획하는 모든 규모의 조직에 여전히 귀중한 인사이트를 제공할 수 있다고 생각합니다.

우리 여행의 간략한 역사

Microsoft Dynamics는 온-프레미스 제품 세트로서 깊은 역사를 가지고 있습니다. Microsoft는 클라우드가 제공하는 많은 이점을 위해 클라우드를 채택했으며, SaaS를 제공하기 위해 이동하면서 기술 및 비즈니스 모델이 적응해야 한다는 것을 알고 있습니다.

우리가 직면한 첫 번째 결정은 새로운 것을 구축하거나 온-프레미스 애플리케이션을 클라우드 서비스로 발전시키는 것 중에서 선택하는 것이었습니다. Dynamics 365의 경우 두 가지를 믿었습니다. 첫째, 데이터 모델과 비즈니스 논리에는 수천 명의 고객에게 기존 솔루션을 발전시킬 만한 가치가 있음을 확인하고 검증한 충분한 가치가 있었습니다. 둘째, 온-프레미스 제품의 계층화된 아키텍처 및 플랫폼 프레임워크는 처음부터 시작하는 것보다 더 빠르게 훌륭한 클라우드 아키텍처를 채택할 수 있는 올바른 레버를 제공했습니다. 가치와 속도의 조합은 클라우드 네이티브 원칙을 채택할 수 있다는 이해와 함께 클라우드 기반 SaaS로 전환하고 Dynamics 365에 적합한 지속적인 개선을 만들었습니다. 다른 조직은 우선 순위가 다르고 다른 전략을 세일 수 있습니다.

초기에 Microsoft Azure 플랫폼에서 빌드할 수 있는 최상의 제품을 빌드하는 데 집중하기로 결정했습니다. 클라우드 플랫폼은 빠르게 개선되며, 여러 클라우드에 리소스를 분산하는 대신 하나의 플랫폼의 풍요로움을 활용하려고 했습니다. 다른 SaaS 공급업체는 자신의 상황에 따라 다른 결정을 내릴 수 있습니다. 예를 들어 수평 플랫폼 공급자는 고객이 여러 클라우드에서 사용할 수 있는 소프트웨어를 빌드할 수 있으므로 각 클라우드 플랫폼에 있는 것이 좋습니다. 그러나 SaaS 애플리케이션 개발자는 하나의 클라우드에 집중하고 하나의 클라우드 공급자와 그 진화에 초점을 맞추는 이점을 얻을 수 있습니다. Dynamics 365의 경우 Microsoft Azure에서 올인하면 강력한 보안 및 고성능을 유지하면서 더 통합되고 원활한 환경을 제공할 수 있다는 것을 알고 있습니다.

Azure 플랫폼을 심층적으로 살펴보고 SaaS 여정을 계획하면서 클라우드에서 대규모 ERP(엔터프라이즈 리소스 계획) 플랫폼을 운영하고 확장하는 방법을 알아보았습니다. 동시에 Azure는 더 풍부해지고 더 유능해졌으며, 상상도 할 수 없었던 새로운 기능을 도입했습니다. 클라우드의 지속적인 진화는 마이그레이션이 일회성이 아닐 것임을 알고 있었습니다. 대신, 우리는 여정의 모든 단계에서 지속적인 개선에 대해 생각했습니다. 지속적인 개선은 우리가 하는 모든 사항에 영향을 미치며, 초기 단계에서는 전체 아키텍처에서 데이터베이스 쿼리 처리 방법에 이르기까지 중요한 변경을 수행해야 했습니다. 클라우드에서 사용할 수 있는 기능을 최대한 활용하기 위해 솔루션을 지속적으로 발전시키고 있습니다. 마이크로 서비스 아키텍처를 수용했으며, 지속적인 발전의 일환으로 생성 AI를 사용합니다. 이러한 접근 방식과 기술은 Microsoft Azure와 같은 강력한 클라우드 플랫폼을 사용할 때 더 쉽게 빌드, 배포 및 작동할 수 있습니다.

클라우드에서 지속적인 개선의 핵심 요소는 원격 분석입니다. 효과적인 원격 분석을 사용하면 개별 기능 수준까지도 애플리케이션을 사용하는 방법과 애플리케이션의 성능을 이해할 수 있습니다. 원격 분석은 문제를 재현하고 디버깅하는 것과 같은 기존 온-프레미스 접근 방식을 따르는 대신 발생한 문제를 파악하여 문제를 해결할 수 있는 인사이트를 제공합니다. 원격 분석을 사용하면 실제 데이터를 기반으로 엔지니어링 결정을 내리고 실험 및 데이터를 통해 제품 가설을 확인할 수 있습니다. 원격 분석 인프라를 만드는 것은 가급적 빨리 이루어져야 하며, 보존되는 데이터와 보존 기간, 관리 방법에 대한 올바른 정책과 함께 이루어져야 합니다.

애플리케이션에서 관리하는 데이터에 대한 데이터 분류 및 보존 정책을 이해하려면 SaaS로의 여정의 일부로 주의해야 합니다. SaaS 공급자로서 현재 및 새로운 데이터 개인 정보 보호법에 따른 책임은 고객이 직접 배포하고 실행한 소프트웨어를 제공한 경우와 다릅니다. SaaS 공급자로 적용되는 데이터 개인 정보 보호 규정을 이해해야 합니다. 또한 클라우드 여정을 시작할 때 데이터 분류 및 보존 프로세스를 준비해야 합니다.

여정을 어떻게 준비했는지

MVP 범위 지정

이 전략은 가능한 한 빨리 고객에게 솔루션을 제공하고 SaaS의 고유한 과제와 기회에 대해 배우기 시작할 수 있도록 MVP(최소 실행 가능한 제품)를 구축하는 데 중점을 두었으며, 이 초점은 전략적 선택이었습니다. 클라우드에서는 신속한 학습과 반복이 필수적이며 MVP를 정의하는 것이 시작이라고 생각합니다.

최소 실행 가능한 제품 용어는 종종 오해됩니다. MVP의 두 특성이 모두 똑같이 중요하다는 점을 고려해야 합니다.

• 최소: 고객에게 가치를 빨리 창출할 수 있는 방법을 찾아보세요. 고객이 솔루션을 더 빨리 사용할수록 솔루션을 사용하는 방법과 솔루션을 계속 개선할 수 있는 방법을 더 빨리 배우기 시작합니다.
• 실행 가능한: 누군가가 실제 가치를 얻을 수 있을 만큼 충분히 완성되도록 제품의 범위를 지정하는 것이 중요합니다. 처음에는 빌드할 전체 기능의 하위 집합을 선택합니다. 올바른 하위 집합을 선택하는 것이 중요합니다. 실행 가능한 최소 구성이 너무 작다면, 고객은 제품을 사용하지 않으며, 발전에 필요한 피드백을 얻지 못합니다.

Dynamics 365의 경우 출시부터 고객이 바로 사용할 수 있는 제품을 만드는 데 집중했습니다. 그런 다음 고객이 어떻게 가치를 얻었는지 알아보고 많은 피드백과 원격 분석을 얻었습니다. 이 데이터를 활용하여 제품 개발 과정을 개선하고 발전시키면서 지속적으로 반복했습니다.

우리의 전략은 새로운 고객이 좋아하는 제품을 구축하는 것이었습니다. 기존 온-프레미스 고객으로부터의 마이그레이션을 더 쉽게 만드는 방법에 대해 의도적으로 설명해 왔지만, 마이그레이션은 훌륭한 최신 제품을 빌드하는 것에 비해 보조적인 초점이었습니다. 이 전략은 새 고객이 처음부터 Dynamics 365에서 완전한 경험을 갖게 됨을 의미했습니다. 그들은 또한 우리에게 귀중한 피드백을 제공했고, 신선한 눈의 혜택으로 그렇게했습니다. 온-프레미스 Dynamics 제품에 아직 많은 투자를 하지 않았기 때문에 클라우드 네이티브 제품과 완전한 SaaS 제품을 빌드하는 데 도움을 주었습니다. 기능을 지속적으로 개선하고 확장하면서 기능 집합이 온-프레미스 제품의 상위 집합인 지점에 도달했습니다. 이 시점에서 기존 고객을 온-프레미스 버전에서 고급 Dynamics 365로 전환하는 것을 지원할 수 있습니다.

ERP 시스템에서 잘 작동할 것이라는 것을 알았기 때문에 이 전략을 의식적으로 선택했습니다. 다른 제품에서는 제품 기능의 하위 집합을 선택하여 먼저 이동한 다음 시간이 지남에 따라 더 많은 기능을 추가할 수 있습니다. 그러나 ERP에서는 구성 요소가 긴밀하게 상호 연결됩니다. 이 제품은 이러한 모든 구성 요소에 기능 조각이 있을 때까지 유용하지 않으므로 고객에게 유용한 엔드 투 엔드 환경을 제공합니다. MVP 범위는 각 구성 요소에서 기능의 가로 조각입니다. 새 고객의 사용 사례를 지원하는 종합적인 기능 집합을 선택하기로 결정했습니다.

다른 솔루션의 경우 MVP의 범위를 전체 구성 요소로 지정하는 것이 합리적일 수 있습니다. SaaS로의 여정에 착수할 때 따르는 전략에 대해 의식적인 결정을 내리는 것이 중요합니다. 핵심은 시장에 대한 초기 결과물은 가능한 한 작아야 하지만 실제 사용량을 얻을 수 있을 만큼 충분히 완료되어야 한다는 것입니다.

우리가 계획하고 개선함에 따라, 우리는 고객의 기대도 지속적으로 진화하고 있다는 것을 염두에 두었습니다. 제품을 정확한 현재 상태로 마이그레이션하는 대신, 고객이 사용할 수 있는 제품을 준비할 때까지 고객이 필요로 하는 것을 계획했습니다. 클라우드 마이그레이션과 결합된 SaaS로의 여정은 종종 수개월 또는 몇 년이 걸리는 장기적인 노력입니다. 이 기간 동안 고객 수요의 변화를 놓치지 않는 것이 중요합니다. 그렇지 않으면 최종적으로 도착할 때 고객의 요구를 완전히 해결하지 못하는 항목을 빌드하는 데 상당한 노력을 기울일 수 있습니다.

사용량, 고객 만족도 및 비용

온-프레미스 소프트웨어 수익은 일반적으로 판매 트랜잭션이 발생하는 시점에 인식되며 성공적인 배포 및 채택에 대한 책임은 고객에게 달려 있습니다. 클라우드 SaaS 구독 모델을 사용하면 고객은 종종 몇 명의 사용자 라이선스로 시작하고 솔루션이 입증된 후에만 구독을 확장합니다. 구매하지만 사용하지 않는 모든 좌석은 다음 구독 기념일에 취소될 수 있으므로 위험합니다. 그 결과 SaaS로 전환하면서 비즈니스를 주도하는 데 사용한 상위 메트릭을 변경했습니다.

사용이 허가된 소프트웨어의 온-프레미스 환경에서 가장 큰 초점은 수익이었습니다. 클라우드에서는 사용량과 고객 만족도에 중점을 두었습니다. 이러한 메트릭은 수익 및 수익 성장의 선행 지표가 되었습니다. 성공적인 배포 시간을 최소화하고, 구매하지만 사용하지 않는 라이선스의 가시성을 제공하고, 사용자 및 비즈니스 역할 전체에서 높은 만족도를 유지하기 위해 노력했습니다. 처음부터 고객이 사용하기를 좋아하는 제품을 만드는 데 중점을 두어 왔습니다. 우리는 고객이 제품을 사용하여 가치를 얻을 때 수익이 다음과 같은 것을 경험에서 알고 있습니다. 고객 환경 및 사용량의 우선 순위를 지정하여 성공적인 비즈니스 전략의 토대를 마련합니다.

SaaS를 빌드할 때, 특히 규모가 조정되고 비용이 증가함에 따라 COGS(상품 판매) 비용이 많이 중요합니다. 그러나 먼저 만족도와 사용량의 우선 순위를 지정하는 것이 좋습니다. 좋은 고객 환경을 제공하는 경우 리소스를 보다 효율적으로 사용하고 새로운 플랫폼 기능을 활용하여 서비스 제공 비용을 최적화할 수 있습니다. 경험이 충분하지 않으면 사용량이 줄어들고 충족시킬 고객이 적어집니다. 따라서 진행 상황을 검토할 때 중요도 순으로 세 가지 주요 성과 지표에 집중합니다.

• 고객 만족도: 고객이 제품 사용 환경을 좋아하나요? 그들의 피드백은 무엇입니까?
• 사용량: 사용자가 몇 명입니까? 구독은 몇 개입니까? 사용량이 가속화되고 있나요? 구매와 사용 시간 사이의 시간은 어떻게 됩니까? 고객이 구매하는 모든 구독을 사용하도록 어떻게 장려할 수 있나요?
• COGS: 고객에게 서비스를 제공하는 데 드는 비용은 얼마인가요?

또한 SaaS 제품이 수익을 창출하는 방법에 대해서도 고려해야 합니다. 고객은 서비스에 대한 요금을 지불하는 방법을 이해해야 하며 가격 책정 모델이 타당해야 합니다. 많은 비즈니스-비즈니스 SaaS 솔루션에서 고객이 가지고 있는 사용자 수는 사용자가 시스템을 사용할 때 소비되는 리소스를 잘 나타내는 지표입니다. 시스템을 적극적으로 사용하는 사용자가 많을수록 좋은 환경을 제공하기 위해 더 많은 시스템 리소스가 필요합니다. 고객에 대한 비용은 그 사실을 반영합니다. 고객은 사용자 기반 가격 책정 구조를 직관적으로 이해할 수 있습니다.

그러나 사용자 수가 고객이 소비하는 리소스를 잘 나타내지 않는 경우도 있습니다. 예를 들어 고객의 마케팅 팀이 전자 메일 캠페인을 위해 많은 수의 메시지를 보내는 경우 한 명의 사용자가 수백만 개의 전자 메일 메시지를 보낼 수 있습니다. 마찬가지로 사용자가 아닌 백그라운드 프로세스는 주문 세부 정보를 가져옵니다. 고객은 청구되는 메트릭을 이해하고 청구서를 예측할 수 있는 것이 중요합니다. 전자 메일 메시지를 보내는 연락처 수 또는 매월 처리하는 주문 줄 수와 같은 미터를 사용하도록 선택할 수 있습니다.

Dynamics 365의 아키텍처

ID, 인증 및 권한 부여

Dynamics 365와 같은 비즈니스 애플리케이션은 고부가가치 비즈니스 데이터를 관리하고 중요 업무용 비즈니스 활동을 자동화합니다. 권한 있는 사용자만 데이터 및 시스템 작업에 액세스할 수 있도록 하는 것이 중요합니다. 기업은 Microsoft Entra ID를 사용하여 IT 자산 전체에서 이미 사용하는 것과 동일한 도구와 플랫폼을 사용하여 Dynamics 365에 대한 액세스를 관리할 수 있습니다. 고객은 추가 작업 없이 조건부 액세스와 같은 고급 보안 기능을 활용할 수 있습니다. Dynamics 시스템을 보호하는 기능은 Entra 플랫폼에 대한 Microsoft의 지속적인 투자와 함께 계속 진화하고 있습니다.

Dynamics 365는 사용자를 역할에 할당하고 특정 데이터 및 작업에 대한 권한을 해당 역할에 할당합니다. 이 방법은 Entra에서 제공하는 사용자 인증 이외의 권한 부여를 관리하는 일반적인 패턴을 따릅니다. 또한 이 방법은 Dynamics 365가 업무 분리와 같은 모범 사례 비즈니스 요구 사항을 적용할 수 있는 기능을 제공합니다.

테넌트 모델

Dynamics 365를 사용하는 각 조직에서는 데이터를 안전하게 유지하고 다른 조직의 액세스로부터 격리해야 합니다. 각 조직을 테넌트모델링하며, 각 테넌트에는 각각 제품을 사용하고 조직의 데이터로 작업할 수 있는 많은 사용자가 있습니다. 리소스를 공유하면 서비스 실행의 비용 구성 요소가 줄어들지만, 테넌트 격리의 예상 수준을 보장하기 위해 공유가 요구 사항과 균형을 이겨야 합니다. 다행히 Azure 플랫폼은 애플리케이션 공급자가 필요한 격리를 제공할 때 비용의 균형을 맞출 수 있는 풍부한 기능을 제공합니다.

예를 들어 각 테넌트의 비즈니스 데이터를 별도의 SQL 데이터베이스에 유지하는 것이 중요하다고 생각했습니다. 이러한 분리를 통해 데이터와 관련된 엔터프라이즈 신뢰 약속의 중요한 구성 요소인 고객 관리형 키를 사용하여 Azure SQL TDE(투명한 데이터 암호화)를 구현할 수 있습니다. 특히 탄력적 풀을 포함한 Azure SQL은 고객당 별도의 데이터베이스를 허용하면서 비용 효율성을 제공합니다. 인프라 비용을 늘리는 것 외에도 테넌트당 별도의 데이터베이스를 유지하기로 결정하면 관리 복잡성이 증가합니다. DBA(데이터베이스 관리자)가 Dynamics 서비스의 규모로 데이터베이스를 수동으로 관리할 수 없을 정도로 부족하여 관리 작업의 자동화에 상당한 투자를 하게 됩니다. Dynamics 365가 대규모 데이터베이스에서 작동하는 방식에 대한 자세한 내용은 대규모 SaaS 공급자인 Microsoft Dynamics 365 및 Power Platform Azure SQL에서 1M 데이터베이스를 실행하는참조하세요.

솔루션의 모든 계층에 대해 Microsoft의 전략은 네이티브 Azure 플랫폼 기능을 사용하여 테넌트 격리를 적용하고 규모와 복원력을 제공하는 동시에 비용 효율성을 확보하는 것이었습니다. 테넌트 보안의 우선 순위를 지정하고 뛰어난 고객 환경을 제공하면서 시스템을 최적화할 수 있는 장소를 항상 찾고 있습니다.

배포 스탬프

Dynamics 365는 하이퍼스케일에서 작동합니다. 수백만 명의 사용자가 있고 각각 우리의 제품에 의존하는 수십만 명의 고객이 있습니다. 이러한 숫자는 시간이 지남에 따라 계속 증가합니다. SaaS 솔루션은 일반적으로 크기를 조정하기 위해 설계되어야 하며 전 세계 고객을 지원해야 합니다.

클라우드에서 가능한 한 스케일 업에서 스케일 아웃으로 전환하는 것이 중요합니다. 기존 노드를 더 강력하게 만드는 대신 더 많은 노드(스케일 아웃)를 추가하여 추가 수요를 충족할 수 있고 해당 관계가 선형에 근접한 경우 스케일 아웃을 기반으로 하는 접근 방식은 더 높은 규모를 구동할 수 있는 잠재력을 제공합니다. Dynamics 365는 애플리케이션 계층에서 스케일 아웃 모델을 사용합니다. 통합 모니터링은 특정 테넌트에 대한 부하 증가를 감지하고 수요를 충족하기 위해 더 많은 노드를 추가합니다.

테넌트 모델과 확장 아키텍처와 함께 사용할 수 있는 배포 스탬프 패턴을 따르면, 각 스탬프가 고객 집합을 지원할 수 있습니다. 스탬프가 최대 용량에 가까워지면 새 스탬프를 프로비전하고 새 고객을 배포할 수 있습니다. 스탬프를 사용하여 지속적인 고객 성장을 지원할 수 있으며 지역 입지를 새로운 지역으로 확장할 수 있습니다.

배포 스탬프를 사용하면 안정성 혜택도 얻을 수 있습니다. 업데이트를 점진적으로 롤아웃할 수 있으며 안전한 배포 프로세스를 통해 글로벌 플릿 간에 변경 내용을 점진적으로 롤아웃할 수 있습니다. 각 스탬프는 다른 스탬프와 독립적이므로 스탬프에 문제가 발생하는 경우 해당 스탬프에 할당된 고객의 하위 집합만 영향을 받습니다. 스탬프는 문제 또는 오류의 폭발 반경 줄이고 전반적인 재해 복구 전략에 기여하는 데 도움이 됩니다.

모든 아키텍처 결정과 마찬가지로 비즈니스 요구 사항에 따라 배포 스탬프를 사용합니다. 스탬프를 배포하려면 이를 지원하기 위한 인프라 집합을 배포해야 합니다. 스탬프의 최소 크기가 너무 크면 먼저 중요한 고객 대용량에 도달해야 하기 때문에 새 스탬프를 새 시장에 배포하는 것을 정당화하기가 어렵습니다. 또한 고객이 성장함에 따라 스탬프의 리소스를 더 많이 사용하기 때문에 고객의 성장이 제품 사용에 미치는 영향을 이해하는 것이 중요합니다. 이러한 고려 사항은 Dynamics 365와 같은 하이퍼스케일 플랫폼의 경우와 마찬가지로 작은 ISV에 중요합니다.

컨트롤 플레인 및 구성

ISV가 클라우드 기반 SaaS 배달 모델로 이동하면 가장 큰 변화 중 하나는 서비스 운영에 대한 책임을 져야 한다는 것입니다. 대부분의 온-프레미스 소프트웨어에서 고객의 IT 부서는 시스템을 배포, 구성 및 관리할 책임이 있습니다. 고객 스스로 모니터링 시스템을 처리하고 업데이트를 배포할 시기를 결정합니다. 또한 관련된 모든 단계를 실행할 책임이 있습니다. 종종 전문 서비스 통합 파트너는 고객이 환경에서 복잡한 제품을 운영할 수 있도록 도와줍니다. 소프트웨어 공급자는 클라우드 및 SaaS 모델로 전환하여 모든 고객 이러한 모든 활동을 담당합니다. SaaS로 전환하면 ISV의 서비스 및 제어 평면 빌드하여 테넌트 온보딩 및 관리 작업을 자동화해야 합니다. 컨트롤 플레인과 자동화는 상대적으로 적은 수의 고객이 있어도 중요합니다.

복원력 있고 안정적이며 고가용성인 컨트롤 플레인을 설계하는 것이 권장됩니다. 컨트롤 플레인은 SaaS 제품을 빌드하는 과정에서 종종 사후 고려 사항으로 처리됩니다. 그러나 컨트롤 플레인은 제품의 나머지 부분과 동일한 주의로 설계되지 않은 경우 단일 실패 지점이 될 위험이 있습니다. 컨트롤 플레인의 복원력에 대한 적절한 주의가 없으면 컨트롤 플레인 오류가 모든 고객에게 영향을 줄 수 있습니다.

Dynamics 365에는 새 테넌트 온보딩과 같은 작업을 처리하는 서비스 수준 제어 평면이 있습니다. 또한 고객 관리 팀이 서비스를 통해 이러한 작업을 수행할 수 있으므로 유지 관리 작업을 시작하고 구성 자체를 변경할 수 있는 테넌트 수준 제어 평면도 있습니다.

사용자 지정 및 확장성

SaaS 모델의 핵심 가치 제안은 모든 고객이 서비스 코드의 한 버전을 실행한다는 것입니다. 고객이 서비스 코드의 한 버전을 실행하면 문제가 한 번 식별되고 해결되며 모든 고객은 이러한 솔루션의 이점을 신속하게 얻을 수 있습니다. 목표는 고객이 업데이트 테스트 및 배포를 계획하지 않고도 서비스의 한 버전을 지속적으로 발전할 수 있도록 하는 것입니다.

이러한 이점을 얻으려면 온-프레미스 환경에서 실행되는 소프트웨어에 비해 많은 변경이 필요합니다. 예를 들어 회귀 가능성을 줄이기 위해 프로세스 및 절차를 계획해야 합니다.

Dynamics 365 변환에서 투자한 한 가지 영역은 풍부한 모델 기반 확장성 개발이었습니다. ERP 애플리케이션은 다른 중요한 비즈니스 시스템과의 통합을 지원하고 특정 고객의 고유한 기능 요구 사항을 충족하기 위해 확장성을 요구합니다. 온-프레미스 애플리케이션에서 일반적인 소스 코드 수준에서 사용자 지정하는 대신 테넌트별 메타데이터를 통해 데이터 모델을 확장하고 시스템에서 발생하는 이벤트에 따라 확장 논리를 트리거하는 기능을 도입했습니다.

다른 테넌트의 확장 논리에서 발생하는 문제로부터 서비스와 다른 테넌트들을 보호하기 위해 격리 및 거버넌스 기능을 추가했습니다. 이 접근 방식은 고객에게 필요한 수준의 확장성을 제공했지만 모두 동일한 제품 버전으로 계속 실행할 수 있도록 했습니다. 또한 고객이 변경 내용을 병합하고 코드를 다시 빌드하여 확장이 최신 버전의 제품에서 작동하도록 하지 않고도 제품에 업데이트를 제공할 수 있습니다.

사용자 지정은 모든 제품에 대한 요구 사항이 아닐 수도 있지만 제품에 필요한 경우 사용자 지정이 중요한 디자인 요소가 됩니다. SaaS 모델의 핵심 이점을 손상시키지 않고 요구 사항을 충족해야 합니다. 이 요구 사항은 Dynamics 365의 중요한 초점이었습니다. 모델 기반 확장성은 모두 SaaS 가치 제안을 보존하고 고객이 확장을 만들고 유지 관리하는 기능을 향상시켰습니다.

복원력을 위해 Dynamics 365를 설계한 방법

Azure에서 배포 모델을 고려할 때 고려해야 할 중요한 구성 요소는 네트워킹 문제, 전원 문제 또는 가상 머신 유지 관리와 같은 종속 서비스에 문제가 있는 경우 복원력입니다. 인프라가 단일 고객 테넌트를 제공하는 온-프레미스 환경에서는 많은 고객이 각 인프라 구성 요소에 대한 고가용성 전략에 의존합니다. 그러나 클라우드 규모에서 복원력을 고려할 때 고가용성이 필요한 경우가 많지만 충분하지 않습니다. 충분한 규모가 되면 오류가 발생합니다.

현재 Dynamics 365의 핵심 포커스 영역은 중단이 데이터 센터 또는 전체 가용성 영역에 영향을 주더라도 중요 업무용 Dynamics 서비스가 원활하게 작동할 수 있도록 Azure 가용성 영역 전반의 중복성을 대상으로 합니다.

이 사고방식을 사용자 고유의 솔루션에 적용하려면 몇 가지 중요한 사례를 따라야 합니다.

• 모니터링 도구에 투자하여 문제를 신속하게 식별해야 합니다. SaaS를 사용하면 고객이 가동 중단에 대해 알고 서비스를 복원하기 위해 신속하게 참여할 것으로 기대합니다.
• 서비스에 적합한 경우 가용성 영역 및 영역 중복과 같은 플랫폼 기능을 사용합니다.
• 모든 계층에서 복원력을 위해 애플리케이션을 디자인합니다. 예를 들어, 재시도, 회로 차단기, 격벽및 비동기 통신 방식을 채택하는 것과 같은 다른 클라우드 모범 사례도 고려해야 합니다. 이러한 관행은 사용자가 의존하는 다른 서비스가 스트레스를 받는 경우에도 서비스를 정상 상태로 유지할 수 있습니다.
• 특히 인프라 자산에 영향을 미칠 때 솔루션 복구에 역할이 있기 때문에 컨트롤 플레인의 가용성을 고려합니다.
• 복원력에 대한 기능을 구현한 경우 테스트를 실행합니다. 사용하려고 할 때까지 계획 및 기능이 완료되었는지 알 수 없습니다. 정상적인 유지 관리 작업의 일부로 장애 조치(failover) 프로세스를 연습하는 것이 유용할 수 있으며, 가동 중지 시간 없이 유지 관리에 대한 접근 방식과 장애 조치(failover) 메커니즘의 유효성 검사를 모두 제공할 수 있습니다.

Azure Well-Architected Framework 안정성 핵심 요소는 이러한 항목에 대한 훌륭한 지침을 제공합니다.

클라우드 환경에 적응하는 방법

Dynamics 365는 고급 클라우드 네이티브 아키텍처로 발전했지만, ISV는 일반적으로 온-프레미스 환경에서 클라우드로 전환하기 위한 제한적인 리프트 앤 시프트 방식을 사용합니다. SaaS 서비스를 고객의 손에 빠르게 전달하기 위해 MVP 정의하는 모델에 대해 논의했으며, 이는 학습 및 지속적인 개선의 주기를 시작합니다. 그러나 균형이 있습니다. 리프트 앤 시프트은 실제로 리프트, 시프트 및 적응 라고 해야 합니다.

이 문서의 앞부분에서는 가용성 영역 및 기타 클라우드 모범 사례 복원력을 위한설계에 대해 설명했습니다. 일반적인 온-프레미스 디자인 패턴으로 인해 클라우드에서 문제가 발생하거나 비용이 높은 다른 영역도 있습니다. 예를 들어 온-프레미스 애플리케이션에서는 일반적으로 관계형 데이터베이스에 이진 대용량 개체를 저장합니다. 예를 들어 판매 주문과 관련된 PDF 문서를 SQL 데이터베이스에 판매 주문의 일부로 저장할 수 있습니다. 온-프레미스 환경에서 이 방법은 백업 및 특정 시점 복원 함수 간의 일관성을 간소화합니다. 그러나 클라우드에서 데이터베이스에 저장된 큰 개체는 비용이 많이 들 수 있습니다. 또한 Azure Storage Blob은 일관된 백업을 유지하는 데 필요한 간단한 논리를 사용하여 큰 이진 개체 저장을 간소화합니다.

클라우드 변환의 일환으로 수행해야 사항에 대해 생각하는 것이 중요합니다. 더 강력한 클라우드 제품을 생성하는 작업을 수행해야 합니다. 그러나 이를 신속하게 시장에 출시하고 학습 및 지속적인 개선의 선순환을 시작할 수 있는 기회로 사용해야 합니다.

클라우드는 온-프레미스 환경에서 옵션이 아닌 완전히 새로운 솔루션을 실용화할 수도 있습니다. ERP 시스템에서 가장 성능 집약적인 프로세스 중 하나는 제조 자원 계획, 즉 MRP II 입니다. MRP II는 재고, 예상 수신 및 발신 주문 및 제조 요구 사항을 살펴봅니다. 그런 다음 기업이 예상 주문을 충족하기 위해 구입하거나 만들어야 할 사항을 결정합니다. 온-프레미스 Dynamics에서 이 기능은 관계형 저장소에 대해 직접 작동하는 애플리케이션 코드에서 구현되었습니다. 계획 함수는 많은 시스템 용량을 사용하고 오랜 시간 동안 실행되었습니다. 첫 번째 클라우드 버전에서는 온-프레미스 기능이 변경되지 않고 진행되었지만 동일한 규모 및 성능 문제가 발생했습니다. 그런 다음 몇 년 전에 성능에 영향을 주지 않고도 동일한 계획 실행을 완료할 수 있는 새로운 메모리 내 마이크로 서비스를 도입했습니다. 중요한 것은 마이크로 서비스가 제조 시스템의 중요한 핵심이기 때문에 고객이 샌드박스 환경에서 올바른 결과를 생성했는지 확인한 후 옵트인할 수 있는 기능으로 도입했습니다. 더 많은 고객이 새 마이크로 서비스에 피벗됨에 따라 모든 고객이 이전 기능을 더 이상 사용할 수 없도록 마이크로 서비스를 사용하도록 하기 위한 노력을 트리거했습니다. MRP II가 언제든지 몇 분 안에 실행될 수 있는 것이 되면서 조직은 민첩할 수 있습니다. 클라우드는 메모리 내 마이크로 서비스를 만들고 연결하여 실용적이고 좋은 SaaS 엔지니어링 원칙을 통해 서비스의 가장 중요한 부분조차도 고객을 방해하지 않고 발전할 수 있게 했습니다.

기존 고객을 클라우드로 마이그레이션하는 방법

기존 고객 기반의 마이그레이션은 클라우드 서비스를 확장하여 확장하는 가장 빠른 방법이 될 수 있습니다. 그러나 Dynamics 365를 클라우드로 가져왔을 때 처음에는 새로운 고객에 집중했습니다. 두 가지 주요 이유가 있었습니다.

• 이 접근 방식을 통해 간단한 클라우드 마이그레이션을 찾는 온-프레미스 고객에게 단순히 호소하는 것만이 아닌, 스스로의 장점으로 승부하는 SaaS 솔루션을 제공했는지 여부를 평가할 수 있었습니다.
• MVP에 집중하고 기존 고객을 마이그레이션하기 위한 도구 빌드와 같은 작업을 연기할 수 있습니다.

새 고객과의 관심을 본 후 기존 온-프레미스 고객을 마이그레이션하는 데 집중할 수 있었습니다.

우리는 고객이 이동의 비용과 복잡성을 두려워하는 경우가 많다는 것을 발견했습니다. 비용을 줄이고 알 수 없는 요소를 제거하는 도구를 제공하는 것이 중요했습니다. 클라우드 제품에서 진화한 새 스키마로 데이터를 마이그레이션하는 데 관련된 노력을 분석하고 마이그레이션이 고객의 확장 및 통합에 미치는 영향을 이해하는 데 도움이 되는 도구를 개발했습니다. 또한 마이그레이션 시간과 비용을 중심으로 경계를 두는 다른 도구와 프로그램을 빌드하는 것이 유용하다는 것을 알게 되었습니다.

클라우드로만 전환하면 온-프레미스 제품에 직면하는 시스템 관리 부담의 상당 부분을 제거하여 고객에게 이익이 되지만 클라우드 버전의 이점을 강조하는 것도 중요한 동기부여가 됩니다.

Dynamics 365를 SaaS로 운영하는 방법을 알아보았습니다.

MVP를 정의하고 엔지니어링을 완료하여 리프트, 시프트 및 적응한 후에는 고객을 대신하여 SaaS 서비스를 운영하는 데 집중해야 합니다. 이 변환은 엄청납니다. 온-프레미스 환경에서 소프트웨어 공급자는 소프트웨어를 만들고 배송하고, 시스템 통합자는 소프트웨어를 배포하고, 고객의 IT 조직 또는 아웃소싱 공급자가 소프트웨어를 실행합니다. SaaS를 사용하면 SaaS 공급자가 주로 서비스 운영을 담당할 뿐만 아니라 수백에서 수천 명의 고객을 동시에 운영할 책임이 있습니다.

우리는 점점 더 많은 고객을 위해 클라우드에서 Dynamics 365를 운영함으로써 많은 것을 배웠습니다.

Monitor: 서비스 공급자로서 고객은 서비스 상태 문제를 감지하기 전에 이를 감지해야 하며 즉시 해결 작업을 수행할 것으로 기대합니다. 상태 문제는 서비스가 중단된 경우에만 발생하는 것이 아닙니다. 비정상인 서비스에 대한 고객의 보기에는 서비스가 느리게 수행되거나 잘못 동작하는 것이 포함됩니다. 적절한 모니터링 도구를 개발하는 것이 필수적입니다. 이 개발은 선택적 액세서리가 아니라 서비스의 일부입니다.

커뮤니케이션: 온-프레미스 환경에서 고객은 IT 팀이 문제를 해결하는 것을 볼 수 있습니다. 클라우드에서는 할 수 없습니다. 서비스 상태 문제를 감지할 때 통신하는 것이 중요하며, 해결로 진행하는 동안 계속해서 진행 상황을 전달하고, 문제가 해결될 때 모든 명확함을 확인하는 것이 중요합니다. 통신의 특성은 문제의 심각도에 따라 달라집니다. 통신 파이프라인은 SaaS 서비스의 핵심 부분이기도 하며, SaaS 서비스 인프라의 핵심 부분이 손상된 경우에도 통신이 성공할 수 있도록 해야 합니다.

전체 스택 보기: 온-프레미스 환경에서 애플리케이션 공급자는 일반적으로 애플리케이션 구성 요소를 담당하며 고객은 기본 인프라를 소유합니다. 클라우드에서는 전체 스택을 담당합니다. 서비스에 상태 문제가 있는 경우, 고객은 문제가 애플리케이션에 있는지 또는 실행되는 클라우드 플랫폼에 있는지 여부를 당신이 감지하고, 소통하며, 복구해 주기를 기대합니다.

자동화: 사용자들이 서비스 운영에서 수동 단계를 수행해야 하는 경우 필연적으로 실수가 발생합니다. 가능한 모든 작업을 자동화하고 기록해야 합니다. 충분한 서비스 노드에서 작업이 필요한 경우 자동화가 유일한 옵션입니다. Dynamics 365에 대한 데이터베이스 관리가 좋은 예입니다. 각 테넌트의 데이터를 별도의 Azure SQL 데이터베이스에 유지하기로 결정하면서 DBA에서 일반적으로 수행하는 모든 작업(예: 인덱스 유지 관리 및 쿼리 최적화)을 처리하는 자동화를 개발해야 했습니다. 대규모 데이터베이스를 관리하는 방법에 대한 자세한 내용은 대규모 SaaS 공급자 대한 Azure SQL에서 1M 데이터베이스 실행참조하세요.

안전한 배포: 가능한 경우 변경 내용이 안전한 배포 프로세스를 따라야 합니다. 첫째, 낮은 위험 환경(예: 고객이 적거나 덜 중요한 워크로드가 있는 클라우드 지역)에 변경 내용이 도입됩니다. 다음으로, 모든 고객이 업데이트될 때까지 약간 더 크고 복잡한 고객 그룹으로 진행합니다. 모든 단계에서 변경이 성공했는지 여부를 평가하기 위한 모니터링이 필요합니다. 문제가 있는 경우 프로세스는 변경 롤아웃을 중지하고 문제를 완화하거나 이미 배포된 위치로 롤백해야 합니다. 안전한 배포 방법은 코드 및 구성 변경 내용 모두에 적용됩니다. 자세한 내용은 안전한 배포 사례참조하세요.

라이브 사이트 인시던트 관리: 라이브 사이트 인시던트는 고객이 프로덕션 환경에서 우리의 서비스에 문제가 발생하여 엔지니어링 측의 개입이 필요한 상황을 의미합니다. 감지한 상태 문제 또는 지원 팀이 자체적으로 해결할 수 없다고 고객이 보고한 문제일 수 있습니다. 라이브 사이트 우수성은 SaaS 성공에 매우 중요합니다. 우리의 경험에서 나온 몇 가지 핵심 사항은 다음과 같습니다.

• 엔지니어링 팀은 라이브 사이트 인시던트 처리해야 합니다. 과거에는 많은 회사에서 별도의 운영 또는 지원 엔지니어링 팀을 운영했습니다. 핵심 엔지니어링 팀이 라이브 사이트 인시던트를 다루도록 명시적으로 선택했습니다. 그들은 최고의 전문 지식을 가지고 있으며, 문제를 직접 보는 것은 실제적이고 빠른 개선과 더 나은 미래 디자인을 추진하기 위해 올바른 창의성과 에너지에 영감을 줍니다. 개발 일정을 계획할 때 고려해야 하는 사항이지만 훌륭한 결과를 가져옵니다.
• 라이브 사이트 인시던트 리더십은 기술이며, 이를 인식하고, 교육하고, 고용하는 법을 배우고, 보상하는 것은 어려운 일입니다.
• 우선 순위는 검색, 격리 및 완화여야 합니다. 고객을 다시 건강하게 한 다음 장기적인 개선에 대해 걱정하세요.

배우고개선 : 누군가가 한 번 말했습니다, "위기를 기회로 삼아야 합니다." 모든 라이브 사이트 사건은 개선할 수 있는 기회입니다. 완화가 완료된 후 유사한 문제를 더 빠르게 감지하는 방법, 문제를 완전히 치료하기 위해 기본 문제를 해결하는 방법, 유사한 문제의 영향을 최소화하는 방법, 다른 유사한 문제가 서비스의 다른 곳에 있는지 여부 및 전체 문제 클래스를 방지하는 방법을 물어보세요. 이러한 수정 작업의 우선 순위를 지정하면 서비스 품질이 향상되고 향후 라이브 사이트 인시던트에 대한 수요가 줄어듭니다. 서비스 품질은 시간이 지남에 따라 개선되어야 합니다. 그렇지 않으면 성장함에 따라 모든 문제의 영향도 높아집니다.

Shift left: 라이브 사이트 팀의 참여가 필요한 문제는 비용이 많이 듭니다. 문제가 해결되려면 시간이 걸리며, 라이브 사이트 팀은 가장 심각한 서비스 상태 문제 및 관리 작업에 사용할 수 있어야 하는 부족한 리소스입니다.

가능한 경우 가장 좋은 솔루션은 문제를 완전히 제거하고 자동화된 검색 및 자동화된 완화를 통해 신속하게 해결하는 것입니다. 이것이 불가능한 경우 왼쪽 이동하는 최전방 지원 팀이 문제를 감지하고 수정하거나 작업을 수행하거나 고객이 스스로 셀프 서비스하고 작업을 수행할 수 있도록 권한을 부여하는 데 도움이 됩니다. 다음 다이어그램에서는 고객 지원 사례를 시작하고, 최전방 지원 팀으로 이동한 다음, 엔지니어링 팀으로 이동하는 방법을 보여 줍니다. 화살표는 인시던트의 영향을 줄이기 위해 해결 작업을 왼쪽으로 이동했음을 나타냅니다.

왼쪽을 가리키는 화살표가 지시하는 해상도 동작을 보여 주는

표준유지: 한 고객을 위해 특별한 준비를 함으로써 문제를 완화하는 것이 좋을 수 있습니다. 대규모로 특수한 모든 항목은 다른 항목이 실패하게 만드는 코너 케이스가 됩니다. 표준 코드, 설정 및 구성을 사용하여 모든 테넌트 유지를 목표로 합니다.

지속적인 혁신

이 문서 전체에서 제품을 클라우드로 가져와 지속적인 학습 및 지속적인 개선의 선순환을 시작해야 하는 필요성에 대해 설명했습니다. 지속적인 혁신은 대부분의 SaaS 제품에 대한 기대입니다. 그러나 SaaS 제품이 오랜 온-프레미스 제품의 후속 제품인 경우 지속적인 혁신을 위해 고객을 준비하기 위해 상당한 변경 관리가 필요합니다.

Dynamics 365 변환의 세 가지 주요 포커스 영역은 다음과 같습니다.

거의 중단 없는 유지 관리: 다양한 비즈니스 및 위치의 고객 수가 증가함에 따라 모두가 수용할 수 있는 유지 관리 기간을 찾는 것이 불가능해집니다. 시스템이 온라인인 동안 유지 관리 작업이 발생할 수 있도록 엔지니어링 완성도를 구축해야 합니다. 특히 서비스 업데이트 배포는 가동 중지 시간으로 가능한 한 0에 가깝게 발생해야 합니다.

회귀 제거: 지속적인 혁신 정책을 사용하여 중요 업무용 서비스에 의존하려면 고객의 신뢰가 필요합니다. 이러한 신뢰는 매일 성공적인 작업과 모든 원활한 서비스 업데이트와 함께 작은 감소로 획득됩니다. 안타깝게도 회귀가 발생하면, 아무리 작은 것이라도 빠르고 대량으로 손실됩니다. 특히 안전한 배포 프로세스를 사용하여 엔지니어링 프로세스의 회귀를 제거하도록 할 수 있는 모든 작업을 수행하는 것이 좋습니다.

기능 플래그: Dynamics 365 팀은 기능 플래그 프레임워크에 광범위하게 투자했습니다. 전체 서비스, 테넌트 하위 집합 또는 단일 테넌트에 대해 기능 플래그를 사용하거나 사용하지 않도록 설정할 수 있습니다. 기능 플래그를 사용하여 Dynamics 365에서 지원하는 중요 업무용 비즈니스 프로세스의 운영을 방해하지 않고 새로운 기능을 도입할 수 있습니다.

기능 플래그가 도움이 되는 방법은 다음과 같습니다.

• 기본적으로 플래그를 사용하도록 설정하여 간단한 성능 또는 보안 수정을 도입할 수 있습니다. 모든 사람은 즉시 변경의 혜택을 받아야합니다.
• 사용자의 환경, 비즈니스 프로세스 또는 외부에 표시되는 API의 동작을 변경하는 항목은 기본적으로 플래그를 해제하여 도입됩니다.
• 기능 플래그를 변경하면 실행되는 코드가 효과적으로 변경되므로 안전한 배포를 통해 기능 플래그 변경도 관리해야 합니다. 예를 들어 문제에 대한 수정 사항을 도입하고 기본적으로 수정에 대한 기능 플래그를 해제한다고 가정합니다. 원래 버그를 보고한 고객에 대해 플래그를 사용하도록 설정할 수 있습니다. 그런 다음 모든 사용자에 대해 플래그가 켜질 때까지 점점 더 많은 고객에게 플래그를 활성화하며 천천히 진행할 수 있습니다.
• 플래그가 기본적으로 켜져 있고 수정에 문제가 있을 때 수정 사항이 도입되면 플래그를 해제하여 논리적으로 즉시 롤백할 수 있습니다.
• 기능 플래그를 사용하여 미리 보기에서 기능을 선택적으로 공개하거나 사용 중단 프로세스의 일부로 새 고객의 기능을 선택적으로 숨길 수 있습니다.
• 새 기능 플래그 및 테넌트별 기능 플래그 설정을 최전방 지원 및 라이브 사이트 팀에 표시할 수 있습니다. 팀이 문제를 조사할 때 이 정보는 새로운 기능 변경을 채택하거나 배제하는 데 신속하게 도움이 됩니다. 필요한 경우 팀은 기능 플래그의 설정을 조정하여 문제를 완화할 수도 있습니다.
• 마지막으로 기능 플래그의 수명 주기를 관리하여 코드 베이스를 지원하지 않도록 해야 합니다. 완전히 배포되고 입증된 후 코드에서 기능 플래그를 제거하는 프로세스를 설정합니다.

결론

온-프레미스 제품에서 SaaS로 전환하려면 고객에게 소프트웨어를 제공하는 방법의 모든 부분과 비즈니스의 모든 부분에서 상당한 변경이 필요합니다. 문화적 변화는 기술적 변화만큼이나 중요합니다. 즉, 가끔 발생하는 온-프레미스 릴리스 주기에서 일반 릴리스 주기로 전환하는 것은 중요한 변화이며, 라이브 사이트 문화와 프로세스를 채택하는 데는 많은 노력이 필요합니다. 팀이 여정에 대해 잘 준비하고 엔지니어를 넘어 인재 풀을 확장하여 SaaS를 대규모로 운영하는 방법을 아는 사람이 있는지 확인해야 합니다.

많은 조직이 이러한 규모의 전환에서 살아남지 못하며, 특히 이미 클라우드에 기본적으로 있는 새로운 경쟁업체가 있는 경우 그렇습니다. 성공을 위해 자신을 설정하려면 MVP의 범위를 신중하게 지정하고 가능한 한 빨리 프로덕션에 적용한 다음 신속하게 반복하고 개선해야 합니다. 전환 프로세스는 종종 가장 어려운 시기이므로 가능한 한 빨리 클라우드로 전환하는 것이 좋습니다.

저희의 경험에서 얻어가기를 바라는 주요 고려 사항과 사용자 고유의 여정을 위해 내려야 할 몇 가지 결정이 있습니다.

• 자신의 경로를 결정합니다. 풍부한 기능을 갖춘 기존 애플리케이션과 설정된 온-프레미스 고객 기반이 있는 경우 클라우드 기반 SaaS 모델로 이동하는 것이 좋습니다. 모든 제품의 여정은 다르며, 사용자 고유의 요구에 따라 결정과 질문을 개별적으로 고려해야 합니다. 다른 여행에서 영감을 얻되, 자신의 길을 개척하세요.
• 전략을 결정합니다. 설정된 고객과 제품을 보유한다는 것은 우선 순위를 만드는 방법을 결정해야 한다는 것을 의미합니다. 새 고객에게 적합한 제품을 즉시 빌드하는 데 집중할 수 있습니다. 기존 고객 기반을 가능한 한 빨리 새 서비스로 마이그레이션하는 데 집중할 수 있습니다. 이동하는 이유와 중요한 변경을 수행할 수 있는 용량은 사용자가 취하는 방향에 영향을 줍니다.
• 단일 클라우드 또는 다중 클라우드를 사용할지 여부를 결정합니다. 단일 클라우드를 기반으로 빌드하거나 엔지니어링 작업을 여러 클라우드에 분산하는 것이 더 적합한지 고려합니다. 플랫폼 구성 요소를 빌드하는 경우 다중 클라우드 전략이 합리적일 수 있습니다. 애플리케이션을 빌드하는 경우 단일 클라우드 전략은 일관되고 통합된 플랫폼을 사용하는 것 이상의 이점을 제공할 수 있습니다.
• 클라우드에 대해 특별히 계획합니다. 클라우드로 마이그레이션하는 리프트 앤 시프트 접근 방식만으로는 충분하지 않습니다. 클라우드의 탄력성을 활용하는 방법과 클라우드 환경에서 서비스를 운영하는 방법을 계획해야 합니다. 자동화, 복원력, 규모, 보안, 성능 및 관찰성은 모두 중요한 고려 사항입니다. 모든 작업을 미리 수행할 필요는 없지만 로드맵을 계획할 수 있도록 대상을 알아야 합니다.
• SaaS에 대해 특별히 계획합니다. SaaS 비즈니스 모델은 온-프레미스 소프트웨어 배달 방식과 다르게 보입니다. 고객은 평가판 계정, 이해할 수 있는 청구 모델, 완전 관리형 서비스 및 요구 사항에 따라 동적 규모를 기대합니다.
• 도착하고, 배우고, 반복하십시오. MVP 범위를 계획하고, 달성할 수 있는 기준선 성과를 파악한 다음, 신속하게 실현하십시오. 일단 그곳에 있으면 지속적인 개선에 전념하세요.
• 클라우드에 있는 경우 이를 활용합니다. 클라우드는 온-프레미스 솔루션에 없는 많은 기능을 제공합니다. 이 기능에는 대규모, 탄력성 및 클라우드 플랫폼 구성 요소를 사용하여 아이디어를 빠르게 만들고 반복하는 기능이 포함됩니다. 클라우드 환경 외부에서 사용하기 어려운 생성 AI, 마이크로 서비스 및 기타 접근 방식과 같은 기술을 사용하는 방법을 고려합니다.
• 고객의 IT 부서가 됩니다. 엔드 투 엔드 서비스를 제공할 때 고객의 기대치가 바뀝니다. 왼쪽으로 이동하는 방법을 계획합니다. 포괄적인 모니터링 및 자동 복구 기능이 있는지 확인합니다.
• 고객 사용량에 대해 알아봅니다. 서비스를 실행할 때 고객이 제품을 사용하는 방법에 대한 많은 양의 유용한 데이터를 수집합니다. 데이터 문화권을 채택합니다. 고객에 대해, 또 그들이 무엇을 하고 어떻게 하는지에 대해 알아보세요. 데이터가 예상과 다른 것을 나타내면 접근 방식을 변경할 수 있을 만큼 민첩하게 실험해 볼 수 있습니다.
• 업데이트를 통해 지속적인 가치를 제공합니다. 업데이트를 배포하는 시기와 방법을 생각해 보세요. 문제를 신속하게 해결하거나 이전 버전으로 대체하도록 계획합니다. 호환성이 손상되는 변경 사항에 대한 처리 방안을 결정하십시오. 모든 차이 지점은 문제가 발생할 수 있는 기회이므로 특정 고객에 대한 일회성 변경을 방지합니다.

우리가 배운 가장 큰 교훈은 SaaS로의 여정이 결코 끝나지 않는다는 것입니다. 제품 로드맵은 지속적으로 진화하는 살아있는 문서입니다. 백로그에는 항상 새 기능을 추가하고 제품 운영 및 제공 방법을 개선하기 위해 제품을 개선하기 위해 많은 항목이 있습니다. SaaS를 제공하려면 프로세스, 품질에 대한 투자 및 경계를 지속적으로 개선하여 고객에게 안정적이고 안전하며 성능이 뛰어나고 신뢰할 수 있는 서비스를 제공해야 합니다. 생성 AI와 같은 기술의 발전은 이전에는 상상할 수 없었던 기능을 제공할 수 있는 엄청난 기회를 제공합니다.

기여자

Microsoft에서 이 문서를 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.

• 마이크 에렌버그 | CTO, Microsoft Dynamics
• John Downs | 소프트웨어 수석 엔지니어
• 아르센 블라디미르스키 | 수석 고객 엔지니어