2018.07.18

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

Kyle York | Network World
점점 더 많은 기업이 멀티클라우드와 하이브리드 클라우드 컴퓨팅 전략을 채택하면서 클라우드 서비스 업체 한 곳의 툴과 기술에 묶이지 않도록 피하는 것이 더 중요해졌다. 멀티클라우드와 하이브리드 클라우드는 많은 장점을 가져다 준다. 어떤 클라우드 서비스 업체의 애드온 서비스가 자사 비즈니스에 적합한지 고를 수 있으며, 적절한 시기에 베스트 오브 브리드 방식으로 솔루션을 구현할 수도 있다. 멀티클라우드는 또한 달걀을 한 바구니에 담지 않아도 되기 때문에 리던던시와 보안도 추가해 준다.

하지만 이런 멀티클라우드 추세에도 불구하고 기업을 자사 서비스에 묶어두려는 클라우드 서비스 업체의 수법은 여전하다. 여기서는 가장 많이 사용되는 록인 방법과 함께 기업이 클라우드를 개방적이고 상호호환되는 환경으로 만드는 데 필요한 약간의 조언을 제시하고자 한다.



1. 독점 인터페이스
주요 클라우드 인프라 서비스 업체들은 스트리밍이나 오케스트레이션, 서버리스 기능 등 일상적인 작업을 자동화하기 위한 애드온 서비스를 제공한다. 기업 사용자를 좀 더 자유롭게 해 좀 더 가치가 큰 활동에 집중할 수 있도록 한다는 것이 기본 개념이다. 하지만 만약 클라우드 서비스 업체가 독점 API를 사용한다면, 이들 기본 서비스는 바로 업체 종속으로 이어진다. 이를 피하기 위해서는 공개 AP{I를 지원하고 쿠버네티스나 카프카, 테라폼, Fn 같은 오픈소스 툴을 사용해 서비스를 구축하는 클라우드 인프라 업체를 찾아야 한다.

명심해야 할 것은 그저 공개 API를 지원하는 것만으로는 부족하다는 것. 클라우드 서비스 업체는 이를 서비스와 지역 모두에 걸쳐 일관된 방식으로 수행해야 할 필요가 있다. 다시 말해 클라우드 서비스 업체의 공개 API에 대한 접근법이 제각각이지 않아야 한다는 것이다. 이를 평가하는 방법은 클라우드 서비스 업체의 로드맵이 현실적인 자세히 살펴보고, 또 현재는 물론 미래에도 자사의 멀티클라우드 전략을 제대로 지원할 수 있을지 판단해야 한다.

2. 오픈소스 지원 부족
오픈소스 기술은 기업 데이터센터와 클라우드 환경 사이에서 워크로드를 옮기는 과정을 매우 단순화할 수 있다. 클라우드 중립적일 뿐만 아니라 오픈소스 표준이 클라우드 간의 이전도 쉽게 만들어 주고 클라우드 록인도 피하고 멀티클라우드 환경을 촉진한다. 하지만 이런 이점을 실현하기 위해 기업은 오픈소스부터 다른 서드파티 툴까지 폭넓게 제공하는 클라우드 서비스 업체를 골라야 한다. IT 시스템 관리에 데브옵스 접근법을 채택한 기업에는 특히 중요하다.

3. 인증된 협력업체 부족
일부 업체는 자사 플랫폼을 지원하는 서드파티 소프트웨어 및 서비스의 생태계를 제대로 구축했다. 하지만 그렇다고 기업이 이들 툴을 제대로 구현하는 데 도움을 받을 수 있는 인증된 전문 서비스 협력업체나 매니지드 서비스 업체가 충분하다는 것은 아니다. 믿을만한 협력업체를 찾지 못한 기업은 클라우드 서비스 업체의 자체 전문 서비스를 사용하는 데 매일 가능성이 크고, 또한 선택의 폭이 좁으면 추가 비용이나 과제, 위험도 더해질 수 있다.

4. 부적합한 기능들
처음에는 클라우드 서비스 업체가 개방적이고 호환성 높은 환경을 제공하는 것처럼 보일 수도 있다. 하지만 앞으로 DNS나 로드밸런싱, CDN, WAF 같은 서비스를 여러 클라우드에 걸쳐 추가하려고 한다면? 클라우드 서비스 업체가 이런 종류의 2차, 3차 서비스를 지원하는지, 특히 서비스를 다른 서비스 업체 인프라의 엔드포인트에 통합할 수 있는지 확실히 하기 바란다. 만약 클라우드 서비스 업체가 이를 제대로 구현하지 못한다면, 서비스는 전 기능을 갖추지 못할 것이며, 그 잠재력을 제대로 살리지도 못할 것이다.

5. 빈약한 컨테이너 개발 경험
개발자들은 새로운 클라우드 네이티브 앱과 전통적인 앱의 클라우드 마이그레이션을 위해 컨테이너 네이티브 기술을 적극적으로 도입하고 있다. 하지만 이들 역시 클라우드 서비스 업체나 애플리케이션 개발 플랫폼 업체에 종속되는 것을 우려한다. 이유는 대부분 클라우드 서비스 업체가 개발자들의 컨테이너 네이티브 서비스 개발을 지원하는 툴을 제공하지만, 그 과정에서 개발자들이 통합되지도 않고 별도로 분리된 독점 구성요소로 이루어진 메뉴를 이용하도록 하기 때문이다. 이 역시 록인을 위한 조리법일 뿐이다. 이 문제를 피하는 최고의 방안은 개방적이고 표준 기반의 구성 가능한(Composable) 소프트웨어 스택을 제공하며, 컨테이너 우선 생태계의 지원을 받는 클라우드 서비스 업체를 선택하는 것이다.

6. 비 클라우드 워크로드 지원 부족
일부 클라우드 서비스 업체는 비 클라우드 워크로드가 있는 기업을 제대로 지원하는 데 필요한 기술 및 시장 역량이 부족하다. 예를 들어, 이전에 온프레미스 환경의 마이크로소프트 윈도우 기반 워크로드를 제대로 지원하지 못했던 이력의 서비스 업체를 만날 수도 있다. 이런 제한적인 선택폭은 운신의 폭을 좁게 만들고, 수준 이하의 툴이나 기술에 얽매일 수 있다. 전체 기능을 갖추고 견실한 성능 이력을 보유한 클라우드 서비스 업체를 고르는 것이 최선의 방안이다. 또한 클라우드 포털이 이해하기 쉽고 지역 전체에 걸쳐 일관된 역량을 제공하는지도 확인하기 바란다.

마지막으로 기업의 성장과 이에 따른 멀티클라우드 전략의 확장을 지원하는 데 필요한 내부 인력과 업계 전문 지식을 제대로 갖추고 있는지 확인해야 한다.

*Kyle York는 오라클 클라우드 인프라 제품 전략 담당 부사장이자 오라클 Dyn 글로벌 비즈니스 사업부 총괄 책임자이다.  editor@itworld.co.kr


2018.07.18

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

Kyle York | Network World
점점 더 많은 기업이 멀티클라우드와 하이브리드 클라우드 컴퓨팅 전략을 채택하면서 클라우드 서비스 업체 한 곳의 툴과 기술에 묶이지 않도록 피하는 것이 더 중요해졌다. 멀티클라우드와 하이브리드 클라우드는 많은 장점을 가져다 준다. 어떤 클라우드 서비스 업체의 애드온 서비스가 자사 비즈니스에 적합한지 고를 수 있으며, 적절한 시기에 베스트 오브 브리드 방식으로 솔루션을 구현할 수도 있다. 멀티클라우드는 또한 달걀을 한 바구니에 담지 않아도 되기 때문에 리던던시와 보안도 추가해 준다.

하지만 이런 멀티클라우드 추세에도 불구하고 기업을 자사 서비스에 묶어두려는 클라우드 서비스 업체의 수법은 여전하다. 여기서는 가장 많이 사용되는 록인 방법과 함께 기업이 클라우드를 개방적이고 상호호환되는 환경으로 만드는 데 필요한 약간의 조언을 제시하고자 한다.



1. 독점 인터페이스
주요 클라우드 인프라 서비스 업체들은 스트리밍이나 오케스트레이션, 서버리스 기능 등 일상적인 작업을 자동화하기 위한 애드온 서비스를 제공한다. 기업 사용자를 좀 더 자유롭게 해 좀 더 가치가 큰 활동에 집중할 수 있도록 한다는 것이 기본 개념이다. 하지만 만약 클라우드 서비스 업체가 독점 API를 사용한다면, 이들 기본 서비스는 바로 업체 종속으로 이어진다. 이를 피하기 위해서는 공개 AP{I를 지원하고 쿠버네티스나 카프카, 테라폼, Fn 같은 오픈소스 툴을 사용해 서비스를 구축하는 클라우드 인프라 업체를 찾아야 한다.

명심해야 할 것은 그저 공개 API를 지원하는 것만으로는 부족하다는 것. 클라우드 서비스 업체는 이를 서비스와 지역 모두에 걸쳐 일관된 방식으로 수행해야 할 필요가 있다. 다시 말해 클라우드 서비스 업체의 공개 API에 대한 접근법이 제각각이지 않아야 한다는 것이다. 이를 평가하는 방법은 클라우드 서비스 업체의 로드맵이 현실적인 자세히 살펴보고, 또 현재는 물론 미래에도 자사의 멀티클라우드 전략을 제대로 지원할 수 있을지 판단해야 한다.

2. 오픈소스 지원 부족
오픈소스 기술은 기업 데이터센터와 클라우드 환경 사이에서 워크로드를 옮기는 과정을 매우 단순화할 수 있다. 클라우드 중립적일 뿐만 아니라 오픈소스 표준이 클라우드 간의 이전도 쉽게 만들어 주고 클라우드 록인도 피하고 멀티클라우드 환경을 촉진한다. 하지만 이런 이점을 실현하기 위해 기업은 오픈소스부터 다른 서드파티 툴까지 폭넓게 제공하는 클라우드 서비스 업체를 골라야 한다. IT 시스템 관리에 데브옵스 접근법을 채택한 기업에는 특히 중요하다.

3. 인증된 협력업체 부족
일부 업체는 자사 플랫폼을 지원하는 서드파티 소프트웨어 및 서비스의 생태계를 제대로 구축했다. 하지만 그렇다고 기업이 이들 툴을 제대로 구현하는 데 도움을 받을 수 있는 인증된 전문 서비스 협력업체나 매니지드 서비스 업체가 충분하다는 것은 아니다. 믿을만한 협력업체를 찾지 못한 기업은 클라우드 서비스 업체의 자체 전문 서비스를 사용하는 데 매일 가능성이 크고, 또한 선택의 폭이 좁으면 추가 비용이나 과제, 위험도 더해질 수 있다.

4. 부적합한 기능들
처음에는 클라우드 서비스 업체가 개방적이고 호환성 높은 환경을 제공하는 것처럼 보일 수도 있다. 하지만 앞으로 DNS나 로드밸런싱, CDN, WAF 같은 서비스를 여러 클라우드에 걸쳐 추가하려고 한다면? 클라우드 서비스 업체가 이런 종류의 2차, 3차 서비스를 지원하는지, 특히 서비스를 다른 서비스 업체 인프라의 엔드포인트에 통합할 수 있는지 확실히 하기 바란다. 만약 클라우드 서비스 업체가 이를 제대로 구현하지 못한다면, 서비스는 전 기능을 갖추지 못할 것이며, 그 잠재력을 제대로 살리지도 못할 것이다.

5. 빈약한 컨테이너 개발 경험
개발자들은 새로운 클라우드 네이티브 앱과 전통적인 앱의 클라우드 마이그레이션을 위해 컨테이너 네이티브 기술을 적극적으로 도입하고 있다. 하지만 이들 역시 클라우드 서비스 업체나 애플리케이션 개발 플랫폼 업체에 종속되는 것을 우려한다. 이유는 대부분 클라우드 서비스 업체가 개발자들의 컨테이너 네이티브 서비스 개발을 지원하는 툴을 제공하지만, 그 과정에서 개발자들이 통합되지도 않고 별도로 분리된 독점 구성요소로 이루어진 메뉴를 이용하도록 하기 때문이다. 이 역시 록인을 위한 조리법일 뿐이다. 이 문제를 피하는 최고의 방안은 개방적이고 표준 기반의 구성 가능한(Composable) 소프트웨어 스택을 제공하며, 컨테이너 우선 생태계의 지원을 받는 클라우드 서비스 업체를 선택하는 것이다.

6. 비 클라우드 워크로드 지원 부족
일부 클라우드 서비스 업체는 비 클라우드 워크로드가 있는 기업을 제대로 지원하는 데 필요한 기술 및 시장 역량이 부족하다. 예를 들어, 이전에 온프레미스 환경의 마이크로소프트 윈도우 기반 워크로드를 제대로 지원하지 못했던 이력의 서비스 업체를 만날 수도 있다. 이런 제한적인 선택폭은 운신의 폭을 좁게 만들고, 수준 이하의 툴이나 기술에 얽매일 수 있다. 전체 기능을 갖추고 견실한 성능 이력을 보유한 클라우드 서비스 업체를 고르는 것이 최선의 방안이다. 또한 클라우드 포털이 이해하기 쉽고 지역 전체에 걸쳐 일관된 역량을 제공하는지도 확인하기 바란다.

마지막으로 기업의 성장과 이에 따른 멀티클라우드 전략의 확장을 지원하는 데 필요한 내부 인력과 업계 전문 지식을 제대로 갖추고 있는지 확인해야 한다.

*Kyle York는 오라클 클라우드 인프라 제품 전략 담당 부사장이자 오라클 Dyn 글로벌 비즈니스 사업부 총괄 책임자이다.  editor@itworld.co.kr


X