Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

록인

IDG 블로그 | 전문가들이 여전히 믿는 멀티클라우드에 대한 오해 3가지

필자는 미디어나 회의, 교육, 팟캐스트 등등 전문가들이 정보를 공유하는 여러 곳에서 멀티클라우드에 대한 잘못된 이야기를 끊임없이 듣는다. 사실 공들여 만든 가짜 정보도 아니다. 그저 사람들이 자신의 멀티클라우드에 대한 경험을 기반으로 무엇이 진실이고 무엇이 아닌지를 제대로 이해하지 못한 것뿐이다.   필자가 여전히 쫓아다니는 멀티클라우드에 대한 오해 3가지를 소개한다. 멀티클라우드는 록인 문제를 해결한다. 필자는 이미 이 문제에 대한 의견을 밝혔기 때문에 여기서 자세하게 설명하지는 않겠다. 간단히 말해, 하나 이상의 퍼블릭 클라우드 서비스 업체를 이용한다면, 멀티클라우드이기 때문에 한 곳의 클라우드 서비스 업체에 록인되지 않을 것이라고 생각한다. 하지만 그렇지 않다. 특정 클라우드 서비스 업체의 네이티브 서비스를 이용한다면, 멀티클라우드이건 아니건, 기업은 해당 클라우드 업체에 록인된다.  멀티클라우드 서비스 카탈로그 내에 또 하나의 클라우드 서비스 업체가 제공하는 같은 서비스가 있어도, 애플리케이션 내에서 특정 클라우드 서비스 업체의 네이티브 서비스를 이용한다는 사실은 없애지 못한다. 따라서 기업은 특정 클라우드 플랫폼과 밀접하게 연결된다. 대안은 값비싼 리팩터링을 통해 애플리케이션을 다른 퍼블릭 클라우드로 이전하는 것이다. 클라우드 전문가가 록인 방지를 강조하며 멀티클라우드의 장점을 얼마나 자주 이야기할지 생각하면, 가장 흔한 오해일 것이다.  멀티클라우드가 더 저렴하다. 거의 그렇지 않다. 하지만 멀티클라우드의 가치가 클라우드 비용 증가를 정당화한다는 의미는 아니다. 다소 혼란스럽겠지만, 이유를 살펴보자. 대다수 멀티클라우드 배치 환경에서 한 곳 이상의 퍼블릭 클라우드에 대한 배치와 운영 비용은 언제나 단일 퍼블릭 클라우드 배치보다 더 많이 든다. 기업은 멀티클라우드의 이기종성과 복잡성에 대한 대가를 지불하는 것이다. 이 비용은 인력과 운영 툴로 확대된다. 또한 크로스 클라우드 보안 솔루션을 비롯한 여러 가지 솔루...

멀티클라우드 복잡성 록인 2022.02.04

IDG 블로그 | 클라우드 ‘록인’은 현실이다

록인(Lock-in, 종속성)은 퍼블릭 클라우드의 숨겨진 비밀 중 하나이다. 클라우드 엔지니어들은 몇 년 전부터 이 문제를 쉬쉬해 왔지만, 이제는 점점 더 많은 사람이 이야기하고 있다. 필자는 CIO의 “클라우드의 10가지 그늘”이란 기사를 인상적으로 읽었다. 클라우드에 관심있는 사람이라면, 여러 가지 이유로 한 번 읽어볼 필요가 있다.   첫째, 언론에서 클라우드 컴퓨팅의 단점을 다루는 일이 흔치 않다. 클라우드는 항상 미디어의 편애를 받고 있다. 필자도 가끔 반대 의견이 너무 없는 것에 깜짝 놀라곤 하는데, 특히 이제는 모두가 알아야 하는 클라우드 컴퓨팅의 문제를 지적해도 공격을 받곤 한다. 둘째, 이 기사에서 지적한 문제는 심사숙고한 것인 데다가 필자가 몇 년 동안 클라우드에 대해 지적한 성능이나 비용, 록인 등의 문제를 제대로 반영했다. 오해는 말기 바란다. 클라우드는 문제가 별로 없다. 하지만 얼마 안되는 문제라도 클라우드를 본격 도입하기 전에 알아야 할 필요가 있다. 여기서는 이 기사에서 지적한 록인 문제에 대해 좀더 자세히 살펴보자.  “얼핏 보기에 범용 운영체제를 범용 하드웨어에 탑재해 판매하니 범용 비즈니스임이 분명하다. 하지만 어쨌든 클라우드 세계는 의외로 점착력이 강하다. 심지어 클라우드에서 생성한 데이터나 서비스는 이론적으로는 이식성이 있지만, 이들 모든 요소를 한 회사의 클라우드에서 다른 회사의 클라우드로 옮기는 것은 상당히 많은 시간이 드는 일이다.” 클라우드 네이티브는 요즘 인기있는 슬로건이다. 나쁜 소식은 클라우드 네이티브 애플리케이션은 클라우드 호스트의 데이터베이스, 보안, 거버넌스, 운영 툴 등에 대한 의존성이 기본 탑재되어 있다는 것이다. 클라우드 네이티브 애플리케이션을 한 클라우드에서 다른 클라우드로 이전해야 하는 날을 계산하는 것은 로켓 공학처럼 어려운 일이 아니다. 하지만 쉽지는 않을 것이다. 사실이 그렇다. 애플리케이션을 옮길 수는 있지만, 클라우드 록인 때문에 생기는 문제는 업계가 인정...

록인 종속성 클라우드네이티브 2021.07.05

존중은 두려움에서 나온다··· 클라우드 록인을 피하는 6가지 전략

이상적인 세계라면 기업은 클라우드 서비스 제공자와 서로 도움이 되는 전략적인 협력 관계를 구축할 것이다. 하지만 항상 그렇게 되지는 않는다.  시간이 지남에 따라 상황이 바뀌고 많은 경우에 고객과 클라우드 제공자 사이의 관계는 변화에 맞춰 발전하지 않는다. 아니면 비용이 처음에 예상했던 것과 다르거나 서비스 품질이 약속과 다르다. 이유야 어찌되었든 조직이 클라우드 제공자와의 관계를 끊어야 할 필요가 있을 때가 올 수도 있다. 핵심은 필요한 순간에 비즈니스에 부정적인 영향을 끼치지 않고 이를 실시할 수 있는 유연성을 확보하는 것이다. 기업들은 실재적인 ‘망명의 위협(threat of defection)' 전략을 유지해야 한다. 예를 들어, 특정 벤더에 얽매이지 않도록 주의하고 조건이 더 이상 비즈니스 계획과 일치하지 않는 경우에 대비하여 다른 옵션에 대한 가능성을 계속 열어 둬야 한다. 이 전략이 있다고 해서 일정 시점에 반드시 해당 클라우드 제공자와 단절될 것임을 자동적으로 가정하는 것은 아니다. 하지만 상황이 잘못되었을 때를 대비하여 가능성을 열어 두는 것이다. 이런 전략을 구축하고 실천하는 방법에 관한 몇 가지 권고사항을 살펴본다.   유연성과 이식성을 위한 설계 IT서비스 및 컨설팅기업 액센츄어의 CIO 조직 내 상무이사 메림 베시로빅은 “데이터와 애플리케이션을 이동하기 쉽게 유지하는 것이 핵심이다”라고 말했다. 해당 기업은 기업 전체를 디지털 방식으로 혁신했으며 클라우드가 그 핵심이었다. 액센츄어는 현재 인프라의 95%를 클라우드로 운용하고 있다. 베시로빅은 “본격적으로 클라우드를 활용함으로써 네이티브 클라우드 솔루션을 도입하는데 집중할 수 있었다. 우리의 팀은 애플리케이션이 제공하고 소비할 안전하고 표준화된 클라우드 네이티브 제품을 관리하고 지속적으로 도입하는 프로세스를 수립했다”라고 말했다. 지금까지 이런 방식으로 70개 이상의 클라우드 네이티브 서비스가 제공되었다고 베시로빅이 전했다. 그에 따르면 오픈소스 표준...

록인 멀티클라우드 CSP 2019.10.04

IDG 블로그 | 클라우드 네이티브 IT 정책의 위험성

처음에는 클라우드 우대(Cloud Preferred) 정책이었고, 그 다음에는 클라우드 우선(Cloud First) 정책, 그리고 이제는 클라우드 네이티브(Cloud Native) 정책이다. 말은 다르지만, 기본적으로는 같은 것을 가리킨다. 다만 의무적인 퍼블릭 클라우드 사용량만 다른 정도이다. 클라우드 네이티브란 말이 의미하는 것은 특정 퍼블릭 클라우드 서비스 업체에, 수많은 클라우드 네이티브 서비스와 단일 서비스 업체에 모든 것을 걸고 클라우드 컴퓨팅 투자로부터 최대의 성과를 끌어내는 것이다. 결과적으로 보안이나 거버넌스, 스토리지, 데이터베이스, 컴퓨트 등등을 위해 단일 서비스 업체의 클라우드 네이티브 서비스만을 사용하는 것이다. 또한 클라우드 서비스 업체가 제공하는 네이티브 인터페이스가 무엇이든 그것만을 사용한다. 가장 큰 이점은 단순성이다. 한 서비스 업체의 단일 네이티브 인터페이스만 사용하므로 보아니 시스템이나 데이터베이스, 컴퓨트 플랫폼 등에 이기종 환경을 복잡성을 걱정할 필요가 없다. 이들은 모두 한 서비스 업체의 같은 연구개발팀에서 나온 것이기 때문에 통일되어 있고, 잘 통합되어 있다. 클라우드 서비스들이 함께 동작하는 것도 매끄럽다. 클라우드 네티이브 정책은 이런 빠르고 쉬운 배치의 반대급부로 사용할 수 있는 클라우드 서비스가 제한된다. 더 나은 성능과 더 나은 통합이란 약속은 일이 잘못되면 한꺼번에 질식사해 버린다. 단점은 분명하다. 클라우드 네이티브는 업체 종속성을 의미한다. 그리고 일부 록인은 불가피한 것으로, 클라우드 네이티브 인터페이스와 API를 많이 사용할수록 특정 서비스 업체에 대한 예속은 강화된다. 서비스 업체가 원하는 것이 바로 이것이다. IT가 값비싼 독점 데이터베이스와 플랫폼, 소프트웨어 시스템에서 벗어나고자 애쓰고 있는 시대에 클라우드 네이티브 컴퓨팅의 업체 종속성은 대부분 IT 부서에서 받아들이기 힘든 점이다. 필자의 조언은 단순하다. 비즈니스 요구사항에 맞춰 사용하는 기술을 단계를 정하고 기술은 베스트 ...

록인 클라우드네이티브 종속성 2019.02.28

IDG 블로그 | 멀티클라우드라고 업체 종속성이 사라지지는 않는다

필자는 여러 미디어를 통해 멀티클라우드(Multicloud)을 선택하는 주된 이유가 업체 종속성(vendor lockin) 때문이라는 얘기를 들었다. 클라우드 제공업체가 많으면 더욱 독립적일 수 있다는 이 가정의 논리는 이해가 가지만 현실은 크게 다르다.   예를 들어, 클라우드에 애플리케이션이 있고 멀티클라우드 아키텍처를 사용하는 경우 해당 애플리케이션 작업 부하와 관련된 데이터를 AWS, 마이크로소프트 애저, 그리고/또는 구글 클라우드 플랫폼 등 2-3곳에 분산시킬 수 있다. 해당 애플리케이션을 위해 1개의 클라우드를 선택하고 표준 마이그레이션 프로세스를 수행해 구성한 후 실행할 것이다. 대부분의 사람은 이런 마이그레이션의 일환으로써 애플리케이션 작업 부하를 클라우드에 네이티브화시켜야 한다는 사실을 모르고 있을 가능성이 높다. 즉, 애플리케이션을 살짝 또는 대대적으로 변경해 API 관리, 거버넌스, 보안, 저장소 등의 네이티브 클라우드 서비스를 활용하게 되는 것이다. 애플리케이션을 클라우드에 네이티브화하면 해당 애플리케이션에 대해서는 스스로 해당 클라우드 제공업체에 종속되는 것이다. 클라우드 네이티브화 접근방식을 취하지 않으면 해당 애플리케이션을 추후에 다른 제공업체로 마이그레이션하기가 더 쉽겠지만 클라우드 네이티브화가 되지 않아 배치가 덜 최적화된다. 고급 애플리케이션 기능(클라우드 네이티브화)을 사용해 업체 종속성을 인정하든지 종속성 탈피를 위해 독립적이지만 덜 최적화된 앱에 만족해야 한다. 단일 클라우드 또는 멀티클라우드 아키텍처를 사용하는지 여부에 상관없이 종속성의 타협은 똑같다. 물론, 필요 시 다른 퍼블릭 클라우드 옵션을 이용할 수 있도록 아키텍처에 다른 퍼블릭 클라우드가 연결, 통합되어 있는 것은 큰 이점이 된다. 하지만 여전히 클라우드 네이티브화와 종속성 탈피 사이의 상충점은 피할 수 없다. 컨테이너를 사용하거나 휴대 가능한 애플리케이션을 작성해 상충점을 피할 수 있다고 생각할 수도 있다. 하지만 거기에도 문제가 존재한다...

록인 lockin 멅티클라우드 2018.12.20

2018 기업 클라우드 컴퓨팅의 현주소

IDG 커뮤니케이션스가 진행한 2018년 클라우드 컴퓨팅 조사에 따르면, 비즈니스의 동력을 얻기 위해 클라우드 환경에 투자하고 지속적으로 개발하고자 하는 기업의 노력은 계속 되고 있다. 설문에 답한 550개 기관들 중 73%가 하나 이상의 애플리케이션 또는 컴퓨팅 인프라를 클라우드로 이전했다고 답한 상황에서 이제 클라우드 도입은 할 것이냐 말 것이냐가 아니라 ‘어떻게 할 것이냐’의 문제임을 알 수 있다. IDG의 2018 클라우드 컴퓨팅 조사는 IDG 산하 미디어(CIO, Computerworld, CSO, Infoworld, Networkworld)의 독자들을 대상으로 온라인에서 실시되었다. 응답자들은 IT 및 보안 분야의 의사 결정자들로 구성되어 있다. 설문에 참여하기 위해서는 기존에 클라우드를 사용해 왔거나, 사용 계획이 있는 기업이어야만 했다. 또한 각 응답자는 자신이 속한 조직의 클라우드 솔루션 구매 과정에서 스스로가 어떤 역할을 하고, 어느 정도의 영향력을 행사 하는지에 대해서도 답했다. 이번 조사 결과는 기업의 클라우드 도입 동향과 관련한 주요 흐름 몇 가지를 보여준다. 클라우드 서비스 업체가 제공하는 보안에 관한 우려가 줄어든 점, 클라우드 배치의 복잡성 증가, 그리고 서비스 방식 배치 고려 증가 등이 그것이다. 점점 더 복잡해지는 클라우드 환경 클라우드 환경은 날로 성숙해지고 있으며, 경우에 따라서는 점점 더 복잡해지고 있다. 응답자 중 43%는 하이브리드 클라우드만을, 12%는 멀티클라우드만을 사용하고 있었던 반면, 2가지를 모두 사용한다고 답한 비율도 30%에 달했다. 멀티 클라우드 사용의 이점으로는 ▲클라우드 옵션의 증가(59%) ▲더 빠르고 쉬운 재해 복구(40%) ▲다수의 클라우드에 걸쳐 워크로드를 분산시킴으로써 얻어지는 유연성(38% ) 등을 꼽았다. 이처럼 클라우드 환경이 복잡해짐에 따라 클라우드 서비스 업체를 포트폴리오로 바라볼 필요를 느끼는 기업이 많아졌고, 이에 대한 논의도 ...

예산 설문조사 록인 2018.08.17

IDG 블로그 | 록인을 노리는 클라우드 서비스 업체의 엉큼한 수법 6가지

점점 더 많은 기업이 멀티클라우드와 하이브리드 클라우드 컴퓨팅 전략을 채택하면서 클라우드 서비스 업체 한 곳의 툴과 기술에 묶이지 않도록 피하는 것이 더 중요해졌다. 멀티클라우드와 하이브리드 클라우드는 많은 장점을 가져다 준다. 어떤 클라우드 서비스 업체의 애드온 서비스가 자사 비즈니스에 적합한지 고를 수 있으며, 적절한 시기에 베스트 오브 브리드 방식으로 솔루션을 구현할 수도 있다. 멀티클라우드는 또한 달걀을 한 바구니에 담지 않아도 되기 때문에 리던던시와 보안도 추가해 준다. 하지만 이런 멀티클라우드 추세에도 불구하고 기업을 자사 서비스에 묶어두려는 클라우드 서비스 업체의 수법은 여전하다. 여기서는 가장 많이 사용되는 록인 방법과 함께 기업이 클라우드를 개방적이고 상호호환되는 환경으로 만드는 데 필요한 약간의 조언을 제시하고자 한다. 1. 독점 인터페이스 주요 클라우드 인프라 서비스 업체들은 스트리밍이나 오케스트레이션, 서버리스 기능 등 일상적인 작업을 자동화하기 위한 애드온 서비스를 제공한다. 기업 사용자를 좀 더 자유롭게 해 좀 더 가치가 큰 활동에 집중할 수 있도록 한다는 것이 기본 개념이다. 하지만 만약 클라우드 서비스 업체가 독점 API를 사용한다면, 이들 기본 서비스는 바로 업체 종속으로 이어진다. 이를 피하기 위해서는 공개 AP{I를 지원하고 쿠버네티스나 카프카, 테라폼, Fn 같은 오픈소스 툴을 사용해 서비스를 구축하는 클라우드 인프라 업체를 찾아야 한다. 명심해야 할 것은 그저 공개 API를 지원하는 것만으로는 부족하다는 것. 클라우드 서비스 업체는 이를 서비스와 지역 모두에 걸쳐 일관된 방식으로 수행해야 할 필요가 있다. 다시 말해 클라우드 서비스 업체의 공개 API에 대한 접근법이 제각각이지 않아야 한다는 것이다. 이를 평가하는 방법은 클라우드 서비스 업체의 로드맵이 현실적인 자세히 살펴보고, 또 현재는 물론 미래에도 자사의 멀티클라우드 전략을 제대로 지원할 수 있을지 판단해야 한다. 2. 오픈소스 지원 부...

오픈소스 호환성 개방성 2018.07.18

IDG 블로그 | 클라우드 록인, “피할 수 없다면 즐겨라”

어떤 클라우드 서비스 업체가 오픈소스 코드에 가장 인색한지 가장 너그러운지 지적하는 것은 즐거울 지 모르지만, 모든 클라우드 서비스 업체는 오픈소스에 관해 본질적으로 실패라는 것을 기억할 필요가 있다. 왜냐하면, 이들 플랫폼의 본성이 가장 중요한 코드는 개방적으로 라이선스한다고 하더라도 독점 상태를 유지하기 때문이다. 전임 몽고DB 임원이자 드리미오(Dremio)의 CMO인 켈리 스터먼은 사람들이 클라우드를 좋아하도록 하는 모든 코드가 “소프트웨어 역사상 가장 독점적인 소프트웨어 일 것”이라고 지적했다. 그렇다면, 이제 어떻게 해야 하는가? 록인(Lockin)을 좋아하는 사람은 없다. 하지만 업계를 잠깐만 둘러봐도 모든 영역을 록인을 실행하는 한두 업체가 장악하고 있다는 것을 알 수 있다. 윈도우와 오피스라는 헤게모니를 가지고 있는 마이크로소프트부터 애플의 아이폰까지, 그리고 기업 인프라 영역에서는 AWS와 마이크로소프트 애저, 구글 클라우드가 장악하고 있다. 이들 업체가 모두 오픈소스를 좋아하기 때문에 걱정할 것 없다고? 그럴지는 모르지만, 클라우드라는 맥락에서 실질적인 의미를 따져봐야 한다. 예를 들어, 구글의 마일즈 워드가 구글 클라우드 플랫폼의 개방성을 자찬하자 클라우드 구루(Cloud Guru)의 공동 설립자인 앤트 스탠리는 불편한 질문을 던졌다. “그럼 빅 쿼리(Big Query)와 스패너(Spanner) 고객에 대해 이야기해 보자. 뛰어난 기술 플랫폼이지만 종속성이 크다.” 워드는 당황해서 “아파치 드릴과 ANSI SQL. 다음 질문?”이라고 답했다. 토론 과정에서 워드는 구글 클라우드 플랫폼과 같은 플랫모과 이를 구성하는 기반 기술 간의 커다란 격차를 슬쩍 회피했다. 아파치 드릴은 구글 스패너의 진정한 대안이 아니다. 물론 일정 수준에서는 일부 기능을 복제할 수 있겠지만, 스패너에서 가치를 뽑아내기 위해서는 스패너는 물론 이를 뒷받침하는 모든 ...

독점 록인 퍼블릭클라우드 2017.10.26

IDG 블로그 | 클라우드 록인 “생각만큼 나쁘지 않다”

“특정 클라우드에 종속되고 싶지 않다”는 말도 필자가 고객에게서 매일 듣는 말 중 하나이다. 당연하다. 누가 그렇게 되고 싶겠는가? 하지만 클라우드 서비스의 현실은 그렇지 않다. 만약 기업의 애플리케이션을 클라우드로 이전한다면, 그리고 해당 클라우드에서 네이티브 서비스를 이용한다면, 이제 해당 클라우드와 엮어진 것이다. 물론 그렇다고 애플리케이션을 다시 옮길 수 없다는 것은 아니지만, 다시 옮기려면 시간과 돈과 위험성을 감수해야 한다. 기술적으로는 ‘록인’된 것이 아니지만, 다른 클라우드 서비스로 이전하는 것은 저렴하지 않다. 이 때문에 묶였다고 느낄 수 있다. 문제의 핵심은 모든 주요 퍼블릭 클라우드 서비스 업체가 록인을 상쇄할만한 것을 제공한다는 것이다. 분명히 비슷한 플랫폼의 다른 클라우드로 이식할 수 있도록 애플리케이션을 작성해서 배치하겠지만, 해당 퍼블릭 클라우드가 제공하는 네이티브 클라우드 서비스를 사용하지 않으면 애플리케이션의 잠재력을 온전하게 끌어낼 수 없다는 것이 이전을 어렵게 만든다. 보안 서비스나 거버넌스 서비스와의 통합, 고성능 컴퓨팅, 비용 효율성 등을 잃을 수 있다. 다시 말해 약간의 록인을 받아들이지 않으면, 애플맄리케이션이 새로운 클라우드 호스트의 이점을 100% 활용할 수 없다는 것이다. 더 나쁜 것은 네이티브 서비스에 있어서 똑 같은 서비스를 제공하는 서비스는 없다는 것이다. 사용자를 묶어두는 것은 바로 이것이다. 개방형 클라우드 플랫폼의 약속이 아주 뛰어난, 그렇지만 매우 독점적인 퍼블릭 클라우드 플랫폼으로 대체되는 것이다. 비록 이런 록인이 효과적인 클라우드 사용의 대가로 일어나는 것으로 피할 수 없지만, 그 대가가 생각만큼 크지는 않다. 우선은 일단 애플리케이션을 특정 클라우드로 옮기고, 그곳에서 애플리케이션을 ‘클라우드 네이티브’하게 만들고나면, 다시 옮길 가능성이 작다. 물론 기업은 클라우드 서비스 업체의 사업 중단이...

마이그레이션 록인 퍼블릭클라우드 2017.09.14

"기업들이여, 벤더의 개미지옥을 벗어나라"...IDC의 벤더 록인 회피 가이드

시장 조사 업체인 IDC가 발행한 최근 보고서에 따르면, 벤더들이 기업보다 너무도 많이 유리한 상황에 있다. 기업들은 고가의 전환 비용이나 IT 통합, 전체를 커스터마이징한 애플리케이션과 같은 벤더 제어하는 부문으로 인해 현재 사용하고 있는 특정 벤더와의 관계를 끊고 다른 벤더로 전환하기에는 너무 많은 문제가 발생할 수 있다. 이는 벤더 록인(vendor lock-in)으로 알려진 무서운 개미지옥에 빠졌다는 걸 의미한다. IDC 보고서는 앞서 설명한 것 외에도 클라우드와 호스티드 소프트웨어 벤더, 그리고 오픈소스에게도 록인 당할 수 있다고 경고했다. 우선 생각해보자. 자사의 데이터를 이전할 수 있는가? 오픈소스가 특정 벤더의 독점 코드에 의해 둘러쌓여 있지 않는가? 이 보고서는 록인의 폐해에 대해 한 기업의 예를 들어 설명했다. 한 기업의 CPO는 "5년 전, 우리는 고도로 커스터마이징된 뉴텍(New Tech)의 솔루션을 도입했다. 뉴텍의 실패로 야기한 호환성(compatibility) 문제는 수백만 달러 비용을 추가하게 만들었다. 우리는 RFP를 구성하고 뉴텍을 대체할 벤더들을 찾아야 했다"고 말했다. 이 기업의 CIO는 "우리는 5년이라는 시간과 수백만 달러를 투자해 자사의 프로세스에 맞게 뉴텍의 시스템을 커스커마이징했다. 이제와서 뉴텍을 대체하는 것은 실현 가능하지 않다. 아무도 이 독특하고 커스터마이징된 솔루션을 갖고 있지 않기 때문이다. 뉴텍은 자사의 IT 환경을 록인시켰던 것이다"고 말했다. 이 보고서의 이름은 <벤더의 록인을 회피해 벤더와의 관계 제어 유지(Maintaining Control of Vendor Relationships by Avoiding Vendor Lock-In)>다. IDC 애널리스트들은 벤더 록인 취약점을 평가하는 감사 활동에 대한 여러가지 권고안을 만들었다. 이 보고서의 목적은 기업 고객이 벤더와 동등한 입장에서 IT 포트폴리오를 관리하는...

벤더 idc 록인 2016.04.20

구글 후원 클라우드 관리 서비스 본격 출시

구글 벤처스의 후원을 받는 신생 업체로 잘 알려진 클리Qr(CliQr)이 클라우드센터(CloudCenter)란 새로운 서비스를 공개했다. 이 서비스는 기업이 최소한의 작업 만으로 서로 다른 클라우드 서비스 업체 간에 애플리케이션을 이전할 수 있는 것이 특징이다.   클리Qr의 공동 설립자이자 CEO인 고라브 맹글릭은 “기존에는 IT 부서가 단일 클라우드 아키텍처로 복잡한 대규모 통합 작업을 해야만 했다”며, “애플리케이션은 특정 인프라에 묶여 있지 않아야 하며, 어떤 클라우드와도 호환되어야 하고, 클라우드 간을 자유롭게 옮겨다닐 수 있어야 한다”고 강조했다.   클리Qr은 클라우드센터를 클라우드 애플리케이션 관리 플랫폼으로 내세우고 있다. 기업은 자사의 애플리케이션을 클리Qr 컨테이너에 담아서 클리Qr의 저장소에 업로드할 수 있다. 여기서부터는 아마존 EC2 클라우드건 VM웨어나 오픈스택 기반 클라우드에 애플리케이션을 배치할 수 있게 된다. 지원 클라우드 플랫폼은 지속적으로 확대해 나갈 계획이다.   기업은 클리Qr 상에서 자사의 애플리케이션을 구동함으로써 워크로드를 특정 플랫폼에 얽매이지않고 좀 더 쉽게 이전할 수 있다. 맹글릭은 자사의 플랫폼이 특정 워크로드 종류에 맞춰 각 클라우드 서비스 업체와 공조하도록 개발됐기 때문에 성능 향상 효과도 얻을 수 있다고 덧붙였다.   만약 클리Qr의 주장대로라면, 기업은 이 서비스를 통해 서로 다른 클라우드 서비스 간의 자유로운 이전을 통해 비용을 절감하고 고가용성을 유지할 수 있다.   클라우드센터는 클라우드 애플리케이션 관리를 위한 PaaS이다. 윈도우와 리눅스 애플리케이션 모두를 지원하기 때문에 사용자는 기반 운영체제에 대해 염려할 필요가 없다. 애플리케이션에 필요한 DLL이나 라이브러리 등의 관련 파일은 모두 컨테이너에 담아져 클라우드센터 오케스트레이터(O...

구글 애플리케이션 이전 2012.06.27

"클라우드 록인 당하지 마라"…우분투 개발업체 캐노니컬 주장

우분투 개발업체인 캐노니컬에 따르면, 클라우드 인프라스트럭처는 언제나 공개형 표준을 기반이라는 의미를 내포하며, 조직들은 퍼블릭 클라우드 업체로부터 서비스 기능을 선택할 때 하나의 표준만을 지원하는 것이 향후 그들이 만들어내는 문제점을 파악해야 한다.     캐노니컬 부사장 크리스 케년은 클라우드 엑스포 유럽 키노트 세션에서 "전세계 가장 큰 클라우드 업체들 모두가 오픈 소스 기술로 구축했다. 그들 모두가 공개형 표준으로 만드는 것이 아니라 오픈 소스가 그 모든 계획을 보강하는 것"이라고 말했다.  유난히 혁신적인 클라우드 업체를 조심하라  캐년은 "이는 공개형 클라우드가 가장 확장성이 있으며, 싸고 안전하기 때문"이라고 설명했다. 캐년은 클라우드 컴퓨팅의 혁신을 인터넷의 그것과 비유했다. "인터넷이 시작할 즈음에 웹에는 공개형 표준인 HTML이 있었다. HTML의 도래는 오늘날과 같은 웹을 만드는 데 시발점이 됐다."    그는 "기본적으로 록인(Lock-in)은 나쁜 것이다. 클라우드 솔루션에서 조심해야 할 사항은 그것이 등록 상표가 있는 것인가, 클라우드 솔루션들에서 조심해야 할 사항은 클라우드로서 실제로 가상화가 잘 입혀져 있는가다. 그들이 다 같은 것은 아니다. v클라우드(vCloud)는 클라우드 컴퓨팅이 10년동안 검증받을 때 그 자리에 없었다"고 설명했다.    또한 "오라클과 같이 하나의 개발업체에서 제안하는 클라우드 솔루션에서는 높은 수준의 록인이 되어, 그 어떤 것도 조심해야 한다"고 주장했다.    케년은 "이 산업이 가격, 기능, 시스템 가동시간(uptime) 경쟁을 펼치게 될 다양한 퍼블릭 클라우드 제공업체가 존재하는 구조로 전환되고 있다"고 말했다.  ...

시트릭스 우분투 캐노니컬 2012.02.01

구글, 경쟁 웹 서비스로의 이전도 지원

상식적인 비즈니스의 법칙을 조롱이라도 하는 것처럼, 구굴은 사용자들이 구글 독스나 지메일 등 자사의 서비스에서 다른 서비스로 쉽게 옮겨갈 수 있도록 하는 일련의 조처를 단행했다. 이를 통해 자사가 클라우드들 사이에서 첫 번째로 거쳐가는 곳이 되도록 한다는 전략. 클라우드는 이미 많은 소프트웨어 업체들이 차세대 컴퓨팅 환경이 될 것으로 보고 있는 유망 시장이다.   그동안 구글과 아마존, 이베이, 야후 등의 수많은 업체들이 클라우드 기반 서비스를 대대적으로 홍보해 왔으며, 수백만의 사용자가 다양한 웹 기반 서비스를 이용하고 이들 업체의 스토리지에 데이터를 저장하고 있다. 하지만 이메일이나 소셜 네트워킹 사이트를 넘어서 본격적인 클라우드 환경으로의 이전은 기대보다 더디게 이뤄지고 있다.   구글에서 지난 2년 동안 “데이터 해방 전선(Data Liberation Front)”이란 프로젝트를 맡고 있는 엔지니어링 매니저 브라이언 피츠패트릭은 사람들이 자신이 모든 개인 데이터를 넘겨줄 수 있을 만큼 해당 업체를 신뢰하기 어렵기 때문이라고 보고 있다.   피츠패트릭은 “데이터 이전을 쉽게 만듦으로써 신뢰를 얻을 수 있다”고 덧붙였다.   데이터 해방전선은 바로 이점에 초점을 두고 있다. 지난 2년 동안 이들은 데이터를 가져오고 내보내는 과정을 단순화해 바로 사용자들이 구글 애플리케이션으로, 또는 구글 애플리케이션으로부터 데이터를 마음대로 이전할 수 있도록 하는 작업을 해왔다.   피츠패트릭은 “다른 클라우드 컴퓨팅 업체, 예를 들어 아마존의 경우도 데이터를 가져오는 과정은 단순화하는 방법은 제공하지만, 그 어떤 업체도 구글처럼 자사 서비스에서 데이터를 내가는 방법에 자원을 투자한 경우는 없다”고 강조했다.   그동안 많은 기업이 자사의 고객을 계속 유지하는 사업 전략을 펼쳐 왔으며, 가능하면 사용자를 묶어두고,...

구글 클라우드 구글독스 2009.09.14

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.