디지털 Transformation, 데이터센터 & Cloud, 베트남

 

그림 1. Mapping of technology into Core Infrastructure Model

3가지가 필요하다고 생각합니다. 기술과 사람, 프로세스 입니다. 아무리 뛰어난 기술이 있더라도 잘 설계하고 운영할 사람이 없거나 프로세스가 갖추어져 있지 않으면 성공적인 IT 시스템이라고 하기 어렵죠.

그중 프로세스를 제공하는 것, 이것이 바로 MOF(Microsoft Operation Framework)의 존재 이유 랍니다.
MOF 4.0은 정말 쉽게 만들어져 있어요. 누구라도 20분만 읽으면 바로 구현 가능하도록 하는 것이 바로 그 목적 이었답니다. 다른 무엇보다 커뮤니티를 통해 궁금한 내용은 도움을 받을 수 있도록 되어 있는 것이 이전과는 다른 큰 차이입니다. 성공적인 IT, 경험해 보세요.

SaaS에 대한 관심은 나날이 증대되고 있는 것 같습니다.SaaS를 설명하면서 언급하고 싶은 내용이 있습니다. 바로 장애입니다. 인프라 운영 시 장애는 일어납니다. 스위치 장비, 웹서버, 어플리케이션 서버, DB서버, 스토리지를 모두 이중화 하여 장애에 대비한다고 해도, Zero Down 타임을 보장 받을 수 없습니다. 최소화 할 수는 있겠지만, 어떠한 이중화도 100% 운영 시간을 보장할 수는 없습니다. 그렇다면, 발생 가능한 분쟁을 시스템을 운영하는 회사와 고객은 어떻게 해결할 수 있을까요? SLA(Service Level Agreement)가 바로 그것입니다.
모든 IDC에서는 SLA를 통해 고객과 벌어질 수 있는 불편한 상황을 피할 수 있습니다. 대표적인 지표는 서비스 가동율이 있지만, 상세한 항목으로 정의할 수 있습니다. 고객이 지불하는 금액에 따라 인프라 이중화 구성 및 데이터 복구 수준이 정해질 것이므로 정확한 값을 언급하는 것은 의미가 없을 것입니다.

제가 SaaS를 이야기하면서 SLA를 이야기하는 것도 바로 이런 이유 입니다. SaaS를 통해 서비스를 제공받는 고객 역시 SaaS 서비스를 제공하는 업체와 SLA에 대한 부분을 반드시 협의하여 지속적으로 관리 해야 합니다. 예를들어, CRM 서비스의 경우라면 5분, 10분, 30분, 60분 등 고객에 따라 참을 수 있는 다운타임이 있을 것이고, 이 부분에 대한 협의를 진행하며 서비스 비용을 결정해야 한다는 것입니다. (SLA는 업체마다 다르므로, 제가 제시한 값은 샘플값임을 고려하십시요)

블로그를 읽다 보면 Salesforce.com에 대한 이야기가 많이 스크랩되고, 쓰여지는 것을 볼 수 있습니다. Salesforce.com은 SaaS CRM으로 인기를 끌고 있고, 많은 관심을 받고 있는 업체입니다.

지난 주(2007년 3월 둘째 주)에 Salesforce.com 인프라에 장애가 발생하여 5-6시간 동안 서비스가 중단 되었습니다. 2005년 12월 큰 장애 이후, 대규모 장애는 이번이 2번 째 입니다. Salesforce.com의 CRM 서비스를 사용하던 고객들도 영향을 받았지만, 그 보다 더 심각한 영향은 AppExchange Platform을 통해 고객을 획득하던 ISV(Independent Service Vendor)들이 받았습니다. 장애에 대해 ISV 업체들이 할 수 있는 것이 아무것도 없었고 Salesforce.com이 장애를 처리하길 기다리는 수밖에 없었죠. 업체의 말을 빌리면, "우리는 바보처럼 기다릴 수박에 없었어요." 였습니다. 장애는 5-6시간 이었으나 실제로 ISV는 이틀 동안 이나 상품을 팔지 못했다고 합니다. ISV 들은 Salesforce.com이 이런 일이 벌어지는 동안 제대로 설명해 주지 않았다고 불평했습니다.

서비스 운영 관점에서 장애는 발생할 수 있지만, 어떻게 처리하느냐가 중요한 능력 중의 하나입니다. 이런 관점에서 이번 Salesforce.com의 대응 자세는 문제가 있었고, SLA에 대한 중요성이 부각되는 측면이라고 하겠습니다. SLA에 언급되어 있지 않다면 어떤 불평도, 보상도 받기 어려울것이기 때문입니다.

Service Level Agreement (SLA)
A formal written agreement made between two parties: the service provider and the service recipient. The SLA itself defines the basis of understanding between the two parties for delivery of the service itself. The document can be quite complex, and sometimes underpins a formal contract. Generally, an SLA should contain clauses that define a specified level of service, support options, incentive awards for service levels exceeded and/or penalty provisions for services not provided.

가장 많이 받는 질문이 바로 "SaaS와 ASP의 차이점이 뭐죠"라는 것입니다. 이와 비슷하게 가장 많이 받았던 질문이 "혁신(Innovation)이 뭐죠" 였던 것 같습니다.
"왜 이런 질문이 나오는 것일까?" 곰곰히 생각을 해봤는데요 정의에 대해, 즉 개념을 명확히 하고 넘어가지 않았기 때문인 것 같습니다.

SaaS의 정의는 "소프트웨어가 호스팅 환경으로 배포되어, 인터넷을 통해 서비스 되는 것" 입니다.
IDC가 이렇게 정의하고 있고, 마이크로소프트도 역시 동일한 정의를 사용하고 있습니다.
이 정의를 기준으로 하면 "ASP도 SaaS가 맞군" 이라고 말하실 것입니다. 맞습니다. ASP도 SaaS가 맞습니다. 다만, 성숙도(Maturity)가 다르다고 표현하는게 맞을 것 같습니다.
지난 2007년 7월 4일, IT렌털산업협회가 주관한 조찬 세미나에서 "2008년 SaaS 산업 전망과 이슈"라는 내용으로 주제발표를 했습니다.

1단계, Application Hosting, 즉 ASP 모델입니다. 하나의 고객을 위해 1개의 Instance를 띄우게 되고, 고객에게 맞춰서 커스토마이징을 하게 됩니다. 커스토마이징에 많은 비용이 소요되기고, Instance를 개별로 띄우기에 규모의 경제를 실현할 수 없게 되는 단점이 있습니다.

2단계, 본격적인 SaaS Architecture입니다.고객 당 Instance를 하나씩 띄우기는 하지만, 커스토마이징이 아닌 메타데이터를 활용한 Configuration을 통해 고객 설정을 하기 시작합니다. 초기 셋업을 서비스제공자가 아닌 고객이 직접하고, 커스토마이징이 없기에 비용을 절감할 수 있지만 아직 규모의 경제는 실현하지 못합니다.

3단계, Multi Tenant를 실현하고, Congiguration까지 가능한 진화 모델입니다. 하나의 Instance로 다수의 고객을 서비스하기에 규모의 경제가 실현되며 Configuration으로 고객 설정을 하기에 비용절감, 규모의 경제가 실현됩니다.

4단계, Multi Tenant, Configuration, Scalability가 구현된 것입니다. 즉, 성숙된 SaaS 어플리케이션은 이 3가지의 특성을 보여주게 되는 것입니다.

ASP와 SaaS를 구분짓는 것은 어떤 개념상의 차이가 아니고, 비즈니스 상에 어떤 효과를 주는지로 구분하는 것이 맞다는 것입니다.

자동차를 예를들어 설명하겠습니다. 현재 자동차는 휘발유 또는 디젤을 연료로 사용합니다.
여기에 연비가 뛰어나고, 화석 연료의 사용을 줄일 수 있는 전기와 휘발유, 디젤을 병행 사용하는 하이브리드카를 만들었다고 가정해보죠.

하이브리드카는 광의의 개념으로 보면 똑같이 자동차이고, 협의의 개념으로 보면 연료 비용을 절감하고, 화석 연료가 고갈되는 시기를 연장시켜주는 새로운 개념의 차라고 이야기할 수 있을 것입니다.

ASP와 SaaS의 차이도 이와 비슷합니다. 광의의 개념으로 보면 ASP와 SaaS는 조직 내부에서 직접 설치하여 운영하는 방식(on-premise)와 달리 서비스제공자에 의해 설치되고 서비스로 제공되는방식(hosted)임에는 차이가 없지만, 협의의 개념으로 보면 서비스를 이루는 어플리케이션의 아키텍쳐가 개선되어, 규모의 경제 및 ROI를 향상시켜주는 진화된 모델이라고 볼 수 있는 것입니다.

즉 ASP는 어플리케이션의 구조가 고객마다 커스토마이징을 해야하는 구조였기 때문에 1 to many를 구현하지 못하고, 1 to few 구조였기 때문에 규모의 경제를 실현하지 못하는 단점을 가지고 있었다는 것이죠. 어플리케이션의 아키텍쳐가 Configuration, Multi-tenant, Scalability 요소를 갖는다면 진정한 의미의 SaaS라고 부를 수 있이고, 단계적인 개선이 이루어질 때마다 1단계, 2단계, 3단계 SaaS 아키텍쳐라고 부를 수 있을 것입니다.

마이크로소프트의 ITSM, MOF 4.0이 공개되었습니다. IT Service Management를 단순화 하는 것, 모든 IT Pro, CIO, IT 임원들의 관심사항 입니다.

IT Pro들은 어떤 결정을 내릴 것이지에 대해 계속 선택을 해야 하는데, 현명한 선택을 할 수 있도록 돕습니다. IT 서비스의 라이프사이클을 통틀어 계획, 배포, 운영, 관리할 수 있도록 합니다.
MOF 4.0 버전에서는 참조하기 쉬운 형태로 결과에 중점을 두고 설계되어 있습니다. 모든 그룹, 팀, 회사별로 독특하기 때문에 MOF 4.0에서의  Service Management Function(SMF)은 조직 내부의 의사결정 프로세스에서 질문을 통해 도출됩니다. 특정 문제를 해결하기 위해 전체 프레임웍을 사용하든지, 아니면 특정 컴포넌트만 사용하는 것도 가능합니다. 실제적으로 사용될 수 있도록 프로세스에 중점을 두었습니다. 거버넌스, 리스크, 컴플라이언스, 매니지먼트 리뷰, Microsoft Solutions Framwork(MSF)로부터의 베스트 프랙티스 등.

Industry와의 조율을 위해 MOF 4.0은 ITIL, CoBIT, ISO 20000 등의 프레임웍에서 제공하는 베스트프랙티스를 지원합니다. 새로운 MOF 4.0은 IT 라이프사이클에 거쳐 간결하고, 실용적인 가이드를 제공합니다. 또한, 아주 중요한 요소는 온라인 커뮤니티 입니다. IT Pro가 자신의 노하우를 통해 기여할 수 있고, 관련된 내용을 조언하는 등, 안정적이고 비용 효율적인 IT 서비스를 유지할 수 있고, 유사한 업무를 수행하는 사람들과의 서로 함께 협업할 수 있는 플랫폼으로 활용 가능합니다.

MOF 4.0을 다운 받으신 후, MOF 커뮤니티에 가입하시면 됩니다.
블로깅, 포럼 등을 통해 다양한 피드백을 받으실 수 있습니다.

감사합니다.