Platform as a Service(PaaS)란 무엇일까요? 구글의 Google App Engine, Salesforce.com의 Force.com?
정의를 내리는 사람에 따라 조금 다를 수 있지만 비슷한 예가 될 것 같습니다. 

마이크로소프트의 호스팅 환경 기반의 어플리케이션은 BizTalk Service, Exchange Services, Sharepoint Services가 발표되었고, 추가로 SQL Server Data Service가 또한 최근에 발표되었습니다. SQL DBMS를 로컬 서버에 설치하지 않고 구름 위에 놓여있는 서비스로 사용 가능한 것입니다. 마이크로소프트에서는 "마이크로소프트 온라인" 이라는 이름으로 부르고 있습니다. 

사실은 진짜 PaaS 서비스, 즉 Force.com과 유사한 서비스를 마이크로소프트가 준비하고 있습니다. "Titan as a Service"가 바로 그것인데, Titan은 마이크로소프트의 CRM Live 서비스의 코드명이고 xRM이라고 부를 수 있을 것 같습니다.(가칭) 개발자들이 CRM 이외의 멀티태넌트, 워크플로 기반의 어플리케이션을 추가할 수 있는 플랫폼의 역할을 하기 때문입니다.
어느 정도의 커스토마이징, 설정에 대한 범위의 룰, 정책이 결정되면 마이크로소프트가 호스팅 하는 형태의 xRM 어플리케이션이 배포 모델로 추가될 것으로 보여집니다. On-Premise, Partner Hosted, Microsoft Hosted의 세가지 배포 유형에서 Microsoft Hosted의 상세한 옵션의 하나로 PaaS 모델이 추가될 수 있는 것이고 고객에게는 더욱 많은 선택의 기회가 주어질 것으로 보여집니다. 아직 공식적으로 발표된 내용은 아니고, 제 임의적인 생각을 표현한 것임을 밝혀둡니다. 

감사합니다.
PaaS,SaaS,소프트웨어 플러스 서비스,CRM Live,Titan
Trackbacks (0) | Comments (0)
http://hsshin.isblog.net/trackback_post_133.aspx
name
password
homepage
comment
secret
2008년 4월 3일, 마이크로소프트의 S2 이노베이션 Day에서 "소프트웨어 플러스 서비스 전략의 이해"라는 주제로 발표를 진행했습니다. 

SaaS(Software as a Service), 즉 서비스로서의 소프트웨어가 친숙한 용어지요? 하지만, SaaS는 소프트웨어의 배포 모델로 협의의 의미입니다. CRM 솔루션을 사용자의 장비에 설치하지 않고 서비스 제공자의 장비에 설치하여 인터넷을 통해 서비스 형태로 제공받는, 즉 위치를 어디에 둘 것인가가 주요 관심대상이 됩니다. 
서비스를 사용하는 이유는 여러가지가 있겠지요? 비용을 지불하기 전에 미리 사용해 볼 수 있다는 것, 또 IT 장비의 관리 부담을 서비스 제공자에게 전이한다는 것 등이 대표적일 것입니다. 
하지만, 소프트웨어의 장점, 예를들면 라이센스를 한 번 획득하면 원하는 동안은 그대로 사용할 수 있다는 장점, 커스토마이징이 자유롭다는 점등은 놓치기 싫은 이점이지요. 

즉 소프트웨어의 장점, 서비스의 장점이 있는데 서비스로만 모든 IT 업무를 전환한다면, 즉 Trade Off 관점으로 해석한다면 하나의 장점을 포기해야 하는 문제가 있다는 것입니다. 사실은 두 가지의 장점을 종합한 형태로 IT 구성이 충분히 가능한데 말입니다.

S+S의 장점은 크게 5가지 정도를 들 수 있을 것입니다. 
1. Seamless Experience, 즉 디바이스 간의 이동, PC를 사용하다가 이동할 때 모바일 장치를 통해서도 
    동기화된 정보를 그대로 이용할 수 있는 것

2. 고객의 선택에 따라 소프트웨어 형태로 직접 설치 (On-premise), 파트너가 소프트웨어를 설치하여 해당 고객군에게 맞도록 커스토마이징 한 후, 아니면 그대로 호스팅 하는 형태, 마이크로소프트가 호스팅하는 형태로 
크게 3가지 형태로 IT 구성이 가능하다는 것

SOA
3. Federation이 가능하여, 방화벽 내부와 외부간의 시스템간 연동이 가능하다는 것
   예를들면, 금융회사가 고객간의 커뮤니케이션을 Windows Live 메신저로 한다면, 대화 내용을 로깅한다거나
   원하는 작업을 취할 수 없기에 자체적으로 Office Communication Server를 통해 메신저를 설치했을 때
   로깅하거나 하는등의 작업이 가능하겠지만, 고객의 Identity를 확보해야 하는 어려움에 봉착하게 됩니다.
   이러한 어려움을 Windows Live Messenger의 Identity를 OCS가 사용하는 등의 Federation이 가능하다는 것

SOA
4. Composition (조합)
    Mesh-up 같은 작업이 가능하다는 것, 즉 Virtual Earth를 활용하여 교통정보 시스템과 연동한 솔루션을 
    만들어 내는 것

5. 다양한 비즈니스 모델
   소프트웨어 판매, 유지보수 등의 기존의 매출원과 온라인 광고와 연계한 새로운 매출 창출

뭐 이정도가 되지 않을까 싶습니다. 감사합니다.
   
소프트웨어 플러스 서비스,S+S,SaaS
Trackbacks (0) | Comments (0)
http://hsshin.isblog.net/trackback_post_131.aspx
name
password
homepage
comment
secret
Korea SaaS 컨퍼러스에서 "MS의 서비스 비즈니스 전략, 소프트웨어 플러스 서비스" 라는 주제로 
발표를 하게 되었습니다. 관심있는 분들 오셔서 들어주세요. 그리고, 아는 척 해주세요. 같이 이야기 
나누고 싶네요. ^^


SaaS,마이크로소프트
Trackbacks (0) | Comments (1)
http://hsshin.isblog.net/trackback_post_106.aspx
엔시스 12/9/2007 4:51:17 PM
추후 발표 내용 블로그에 좀 올려 주세요^^ 그리고 성공적인 행사가 되시길 바라겠습니다...
 Reply Delete
name
password
homepage
comment
secret
에스크로 제도를 아시죠? 백과사전의 정의에 따르면 에스크로란 미국 법률용어로 특정물을 제3자에게 기탁하고 일정한 조건이 충족된 경우에 상대방에게 교부할 것을 약속하는 조건부 양도증서(條件附讓渡證書)를 말합니다.

SaaS 서비스를 도입하기를 꺼리는 사용자 입장에서 제일 걱정되는 부분이 바로 데이터를 서비스 제공자에게 맡겨야 한다는 것입니다. 예를들면, 아래와 같은 경우가 있을 수 있습니다.

1. 서비스 제공자가 파산하여, 서버 및 스토리지를 채권자에게 압류당한 경우
2. 서비스 제공자와의 분쟁으로 인해 데이터에 대한 접근을 차단 당하는 경우
3. Consumer가 다른 서비스 제공자로 데이터를 이관을 하기를 원할 경우
4. 서비스 제공자의 장애가 장기간 길어지는 경우
5. 해커가 침입하여 데이터를 악용하여 Consumer에게 책임이 전가되는 경우

이런 경우에 대한 두려움이 해결되지 않으면 믿고 맡기기 정말 어려울 것입니다.
이를 해결하기위해 에스크로 제도가 필요할 것입니다.

SaaS 에스크로 서비스는 아래와 같은 서비스를 제공하면 됩니다.
1. SaaS 데이터의 핫백업을 제공
2. 소스코드를 포함하여 SaaS 어플리케이션의 복사본 제공
3. 유사시 에스크로 제공자에게 서비스가 이관시 정상적으로 작동하는 것을 보장하는 검증 테스트

이런 서비스를 제공할 수 있다면 믿고 맡길 수 있을 것입니다.
현재 미국의 www.ironmountain.com 라는 회사가 SaaS 에스크로 서비스를 제공하고 있습니다. 참고하세요.

감사합니다.
SaaS
Trackbacks (0) | Comments (0)
http://hsshin.isblog.net/trackback_post_96.aspx
name
password
homepage
comment
secret
앞의 글에서 SaaS 어플리케이션이 가져야 하는 특징을 몇가지 언급했었습니다. Configuration, Multi-Tenant, Scalablity 3가지가 바로 그것이죠. 하지만, 어플리케이션 아키텍쳐를 위의 특징을 갖도록 바꾸면 바로 SaaS 서비스가 가능할까요?

일반적인 웹 사이트를 개발할 때의 라이프사이클을 생각해보겠습니다. 개발자가 웹사이트를 만들고 나면, 이 웹사이트를 운영해줄 누군가와 서버(H/W, 웹서버, DBMS)가 필요하게 됩니다. 대부분의 경우는 호스팅 업체를 통해 웹사이트를 운영하도록 합니다. 

그럼 SaaS 어플리케이션의 경우는 어떨까요? 서비스 어플리케이션을 만들었다고 가정하겠습니다. 기존 같이 호스팅 업체에 맡기면 될까요? 위의 웹사이트의 경우는 나의 사이트를 맡긴 것이기 때문에 장애가 나면 내가 감당하면 됩니다. 그렇지만, 내가 서비스를 만들었고 고객의 데이타를 다루는 서비스를 운영하고자 하는데 장애가 나면 어떻게 해야할까요? 고객의 중요한 업무가 장애로 인해 중단된 상태인데, 서비스 제공자인 내가 할 수 있는 일은 아무것도 없습니다. 호스팅 업체가 장애를 해결해주기를 기다리는 것 이외에는. 하드웨어 장애의 경우는 호스팅 업체가 해결해줄 수 있지만 어플리케이션 장애의 경우는 내가 해결해야 합니다. 원격으로 접속해서 문제를 해결하기가 대단히 어려울 것입니다. 

그렇다면, 호스팅 업체 대신에 내가 직접 어플리케이션 및 H/W를 운영하는 경우를 생각해보겠습니다. 아시다시피 서비스는 365일, 24시간, 7일 동안 즉 중단없이 운영이 되기 때문에 운영자를 최소한 4명은 두고 4조 3교대 형태를 유지해야 합니다. 1명씩이 근무를 하고 있는데 네트웍, H/W, S/W, 어플리케이션에 대한 모든 장애를 다 감지하고 해결할 수 있을까요? 2명씩 근무를 하는 체제로 바꾸어 8명을 두어야 한다고 가정해보겠습니다. 그래도 다양한 오류를 해결할 수는 없고 무엇보다 비용이 가장 큰 문제입니다. 8명을 유지하기 위해 1개월에 소요되는 기본 비용이 엄청나죠? 이 비용 이상을 서비스로 매출을 올린다는 것은 쉽지 않은 이야기입니다. 

그래서 등장한 해법이 SaaS 호스팅 업체 입니다. 해외에서는 SaaS Hoster라는 용어를 사용합니다. SLA(Service Level Agreement)를 어플리케이션 서비스 업체와 체결하여 그 수준을 맞추며 호스팅 서비스를 제공하는 업체를 말하는 것이죠. 하지만, 국내의 경우는 SLA에 대한 개념이 아직 정착되어 있지 않아 SaaS Hoster는 없다고 보는 것이 맞을 것 같습니다. SaaS를 확산시키기 위해서는 SaaS Hoster를 양성하는 것도 꼭 필요하다는 것을 강조하고 싶습니다.

기억하세요. 어플리케이션 운영을 어떻게 진행하고, 비용 부담을 줄일 것인지가 꼭 고려되어야 합니다.
SaaS,호스팅
Trackbacks (0) | Comments (0)
http://hsshin.isblog.net/trackback_post_85.aspx
name
password
homepage
comment
secret
< PREV 1 2 3 NEXT >