2018.12.21

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

David Linthicum | InfoWorld
멀티클라우드(Multicloud)을 선택하는 주된 이유가 업체 종속성(vendor lockin) 때문이라는 이야기가 흔하다. 클라우드 제공업체가 많으면 더욱 독립적일 수 있다는 이 가정의 논리는 이해할 수 있다. 그러나 현실은 크게 다르다.
 
ⓒ Getty Images Bank 

예를 들어, 클라우드에 애플리케이션이 있고 멀티클라우드 아키텍처를 사용하는 경우 해당 애플리케이션 작업 부하와 관련된 데이터를 AWS, 마이크로소프트 애저, 그리고/또는 구글 클라우드 플랫폼 등 2-3곳에 분산시킬 수 있다.

해당 애플리케이션을 위해 1개의 클라우드를 선택하고 표준 마이그레이션 프로세스를 수행해 구성한 후 실행할 것이다. 대부분의 사람은 이런 마이그레이션의 일환으로써 애플리케이션 작업 부하를 클라우드에 네이티브화시켜야 한다는 사실을 모르고 있을 가능성이 높다. 즉, 애플리케이션을 살짝 또는 대대적으로 변경해 API 관리, 거버넌스, 보안, 저장소 등의 네이티브 클라우드 서비스를 활용하게 되는 것이다.

애플리케이션을 클라우드에 네이티브화하면 해당 애플리케이션에 대해서는 스스로 해당 클라우드 제공업체에 종속되는 것이다. 클라우드 네이티브화 접근방식을 취하지 않으면 해당 애플리케이션을 추후에 다른 제공업체로 마이그레이션하기가 더 쉽겠지만 클라우드 네이티브화가 되지 않아 배치가 덜 최적화된다.

고급 애플리케이션 기능(클라우드 네이티브화)을 사용해 업체 종속성을 인정하든지 종속성 탈피를 위해 독립적이지만 덜 최적화된 앱에 만족해야 한다. 단일 클라우드 또는 멀티클라우드 아키텍처를 사용하는지 여부에 상관없이 종속성의 타협은 똑같다.

물론, 필요 시 다른 퍼블릭 클라우드 옵션을 이용할 수 있도록 아키텍처에 다른 퍼블릭 클라우드가 연결, 통합되어 있는 것은 큰 이점이 된다. 하지만 여전히 클라우드 네이티브화와 종속성 탈피 사이의 상충점은 피할 수 없다.

컨테이너를 사용하거나 휴대 가능한 애플리케이션을 작성해 상충점을 피할 수 있다고 생각할 수도 있다. 하지만 거기에도 문제가 존재한다. 컨테이너는 클라우드간 이동성을 제공하지만 컨테이너를 제대로 활용하려면 대부분의 애플리케이션을 수정해야 한다. 그 비용이 클라우드 네이티브화보다 클 수도 있다. 종속성 탈피에 그만한 가치가 있을까? 상황에 따라 이 질문에 답해야 한다.

게다가 일반적으로 휴대 가능한 애플리케이션을 작성하면 모든 플랫폼과 호환되도록 하기 위해 최소 공통 분모 접근방식으로 이어진다. 이로 인해 클라우드 네이티브화가 되지 않았기 때문에 모든 곳에서 제대로 작동하지 않게 된다. 

여러 클라우드에 네이티브화된 휴대 가능한 애플리케이션을 작성할 수 있겠지만 실제로는 애플리케이션을 사전에 여러 번 작성하고 한 번에 하나의 인스턴스만 사용하게 되는 것이다. 복잡하고 비용이 많이 든다.

종속성은 피할 수 없다. 하지만 종속성은 언어, 툴, 아키텍처, 플랫폼 등 여러 영역에서 피할 수 없는 선택이다. 핵심은 각 종속성을 현명하게 선택해 변경 필요성을 최소화하는 것이다. 하지만 변화가 반드시 필요할 때가 오면 대가를 치러야 한다. 올바르게 선택한다면 그 대가를 그리 자주 지불하지는 않을 것이며 최소 공통 분모 접근방식에서 얻는 것보다 더 많은 것을 얻게 될 것이다. editor@itworld.co.kr 

2018.12.21

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

David Linthicum | InfoWorld
멀티클라우드(Multicloud)을 선택하는 주된 이유가 업체 종속성(vendor lockin) 때문이라는 이야기가 흔하다. 클라우드 제공업체가 많으면 더욱 독립적일 수 있다는 이 가정의 논리는 이해할 수 있다. 그러나 현실은 크게 다르다.
 
ⓒ Getty Images Bank 

예를 들어, 클라우드에 애플리케이션이 있고 멀티클라우드 아키텍처를 사용하는 경우 해당 애플리케이션 작업 부하와 관련된 데이터를 AWS, 마이크로소프트 애저, 그리고/또는 구글 클라우드 플랫폼 등 2-3곳에 분산시킬 수 있다.

해당 애플리케이션을 위해 1개의 클라우드를 선택하고 표준 마이그레이션 프로세스를 수행해 구성한 후 실행할 것이다. 대부분의 사람은 이런 마이그레이션의 일환으로써 애플리케이션 작업 부하를 클라우드에 네이티브화시켜야 한다는 사실을 모르고 있을 가능성이 높다. 즉, 애플리케이션을 살짝 또는 대대적으로 변경해 API 관리, 거버넌스, 보안, 저장소 등의 네이티브 클라우드 서비스를 활용하게 되는 것이다.

애플리케이션을 클라우드에 네이티브화하면 해당 애플리케이션에 대해서는 스스로 해당 클라우드 제공업체에 종속되는 것이다. 클라우드 네이티브화 접근방식을 취하지 않으면 해당 애플리케이션을 추후에 다른 제공업체로 마이그레이션하기가 더 쉽겠지만 클라우드 네이티브화가 되지 않아 배치가 덜 최적화된다.

고급 애플리케이션 기능(클라우드 네이티브화)을 사용해 업체 종속성을 인정하든지 종속성 탈피를 위해 독립적이지만 덜 최적화된 앱에 만족해야 한다. 단일 클라우드 또는 멀티클라우드 아키텍처를 사용하는지 여부에 상관없이 종속성의 타협은 똑같다.

물론, 필요 시 다른 퍼블릭 클라우드 옵션을 이용할 수 있도록 아키텍처에 다른 퍼블릭 클라우드가 연결, 통합되어 있는 것은 큰 이점이 된다. 하지만 여전히 클라우드 네이티브화와 종속성 탈피 사이의 상충점은 피할 수 없다.

컨테이너를 사용하거나 휴대 가능한 애플리케이션을 작성해 상충점을 피할 수 있다고 생각할 수도 있다. 하지만 거기에도 문제가 존재한다. 컨테이너는 클라우드간 이동성을 제공하지만 컨테이너를 제대로 활용하려면 대부분의 애플리케이션을 수정해야 한다. 그 비용이 클라우드 네이티브화보다 클 수도 있다. 종속성 탈피에 그만한 가치가 있을까? 상황에 따라 이 질문에 답해야 한다.

게다가 일반적으로 휴대 가능한 애플리케이션을 작성하면 모든 플랫폼과 호환되도록 하기 위해 최소 공통 분모 접근방식으로 이어진다. 이로 인해 클라우드 네이티브화가 되지 않았기 때문에 모든 곳에서 제대로 작동하지 않게 된다. 

여러 클라우드에 네이티브화된 휴대 가능한 애플리케이션을 작성할 수 있겠지만 실제로는 애플리케이션을 사전에 여러 번 작성하고 한 번에 하나의 인스턴스만 사용하게 되는 것이다. 복잡하고 비용이 많이 든다.

종속성은 피할 수 없다. 하지만 종속성은 언어, 툴, 아키텍처, 플랫폼 등 여러 영역에서 피할 수 없는 선택이다. 핵심은 각 종속성을 현명하게 선택해 변경 필요성을 최소화하는 것이다. 하지만 변화가 반드시 필요할 때가 오면 대가를 치러야 한다. 올바르게 선택한다면 그 대가를 그리 자주 지불하지는 않을 것이며 최소 공통 분모 접근방식에서 얻는 것보다 더 많은 것을 얻게 될 것이다. editor@itworld.co.kr 

X