2020.03.02

IDG 블로그 | “네이티브 vs. 연합” 멀티클라우드 아키텍처 논쟁

David Linthicum | InfoWorld
여러 가지 이유로 멀티클라우드가 새로운 표준이 된 사실을 눈치채지 못하는 사람도 있겠지만, 현실은 록인을 피하고 동급 최강의 클라우드 서비스를 고르는 방식을 놓고 논쟁이 일어나고 있다.

자주 언급했듯이 멀티클라우드는 복잡성을 가져오고 복잡한 아키텍처를 운영해야 하는 과제를 안게 된다. 많은 기업이 이들 배치 환경을 운영, 즉 클라우드옵스로 이전할 수 있으며, 일종의 클라우드 컴퓨팅 중간 지대에 갇혀 있는 기업도 있다.
 
ⓒ GettyImagesBank

하기 좋은 대답은 처음부터 계획을 잘 세웠어야 한다는 것이지만, 기업이 듣고 싶은 대답도 아닐 뿐만 아니라 온당한 평가도 아니다. 무엇보다 생산적인 대답이 아니다. 이들 기업은 멀티클라우드 아키텍처와 함께 앞으로 나아가야 하고, 주된 비즈니스 문제를 해결하는 것은 물론, 운영을 무너뜨리지 않을 최적화된 멀티클라우드 아키텍처로 가는 길을 찾아야 한다.

후보 아키텍처를 살펴보자.

이기종 클라우드 네이티브(Heterogeneous Cloud Native) 아키텍처. 동급 최강의 개별 클라우드 컴퓨팅 배치라는 임무에서 IT 책임자는 자신의 느낌과 관계없이 그 분야 최고의 기술을 고른다. 이 아키텍처는 수많은 클라우드 네이티브 서비스를 서로 다른 퍼블릭 클라우드 서비스로부터 사용하는 것으로 구성되며, 이런 식으로는 정말로 문제가 생긴다.

클라우드 네이티브 환경이 바람직하지 않다는 말은 아니다. 클라우드 네이티브를 잘못된 방식으로 구현하고 있다는 것이다. 문제는 네이티브 클라우드 서비스를 넘어서는 공통의 서비스가 거의 또는 전혀 없다는 데 있다. 10가지 서로 다른 보안 솔루션, 여러 가지 거버넌스 툴, 그리고 10가지가 넘는 관리 및 모니터링 솔루션을 사용해야 한다. 이 모두를 한꺼번에 실행하고 어떤 일이 생기는지 보라.

이기종 페더레이션(Heterogeneous Federated) 아키텍처. 클라우드 컴퓨팅용으로는 오래된 재탕 아키텍처 패턴처럼 보이지만, 사실은 꽤 새로운 방식이다. 이 아키텍처는 컨테이너와 컨테이너 클러스터를 이용할 수 있지만, 이를 다수의 서로 다른 퍼블릭 클라우드에 페더레이티드 호스트로 배치한다.

몇 가지 조건도 필요하다. 우선은 쿠버페드(Kubefed) 같은 표준과 이를 기반으로 컨테이너 클러스터 페더레이션을 사용하는 제품이 시장이 나와야 한다. 둘째, 클라우드 커뮤니티가 이 아키텍처를 바람직한 것으로 받아들이고, 관련 생태계가 형성되어야 한다. 

물론 현재는 어느 것도 준비되어 있지 않다. 이 방식은 멀티클라우드를 향한 또 하나의 아키텍처를 찾아 기존 방식을 버린다는 의미이다. 이기종 클라우드 네이티브의 문제를 살펴보면, 복잡성과의 싸움이 벌어지고 있음을 알 수 있다. 이 문제를 해결하는 논리적인 방법은 보안이나 거버넌스, 관리, 모니터링, 심지어 데브옵스와 툴체인 같은 공통 서비스를 계획하고 개발하는 것이다.

논쟁은 계획 부족(이기종 네이티브)과 계획 과잉(이기종 페더레이션)의 중간에 있으며, 컨테이너나 쿠버네티스 같은 구체적인 표준 구현 기술의 사용을 강제하지도 않는다. 과연 어떤 아키텍처가 이길까? 이기종 클라우드 네이티브와 그 복잡성을 제거하기만 한다면, 어느 쪽이든 모두 좋을 것이다. editor@itworld.co.kr


2020.03.02

IDG 블로그 | “네이티브 vs. 연합” 멀티클라우드 아키텍처 논쟁

David Linthicum | InfoWorld
여러 가지 이유로 멀티클라우드가 새로운 표준이 된 사실을 눈치채지 못하는 사람도 있겠지만, 현실은 록인을 피하고 동급 최강의 클라우드 서비스를 고르는 방식을 놓고 논쟁이 일어나고 있다.

자주 언급했듯이 멀티클라우드는 복잡성을 가져오고 복잡한 아키텍처를 운영해야 하는 과제를 안게 된다. 많은 기업이 이들 배치 환경을 운영, 즉 클라우드옵스로 이전할 수 있으며, 일종의 클라우드 컴퓨팅 중간 지대에 갇혀 있는 기업도 있다.
 
ⓒ GettyImagesBank

하기 좋은 대답은 처음부터 계획을 잘 세웠어야 한다는 것이지만, 기업이 듣고 싶은 대답도 아닐 뿐만 아니라 온당한 평가도 아니다. 무엇보다 생산적인 대답이 아니다. 이들 기업은 멀티클라우드 아키텍처와 함께 앞으로 나아가야 하고, 주된 비즈니스 문제를 해결하는 것은 물론, 운영을 무너뜨리지 않을 최적화된 멀티클라우드 아키텍처로 가는 길을 찾아야 한다.

후보 아키텍처를 살펴보자.

이기종 클라우드 네이티브(Heterogeneous Cloud Native) 아키텍처. 동급 최강의 개별 클라우드 컴퓨팅 배치라는 임무에서 IT 책임자는 자신의 느낌과 관계없이 그 분야 최고의 기술을 고른다. 이 아키텍처는 수많은 클라우드 네이티브 서비스를 서로 다른 퍼블릭 클라우드 서비스로부터 사용하는 것으로 구성되며, 이런 식으로는 정말로 문제가 생긴다.

클라우드 네이티브 환경이 바람직하지 않다는 말은 아니다. 클라우드 네이티브를 잘못된 방식으로 구현하고 있다는 것이다. 문제는 네이티브 클라우드 서비스를 넘어서는 공통의 서비스가 거의 또는 전혀 없다는 데 있다. 10가지 서로 다른 보안 솔루션, 여러 가지 거버넌스 툴, 그리고 10가지가 넘는 관리 및 모니터링 솔루션을 사용해야 한다. 이 모두를 한꺼번에 실행하고 어떤 일이 생기는지 보라.

이기종 페더레이션(Heterogeneous Federated) 아키텍처. 클라우드 컴퓨팅용으로는 오래된 재탕 아키텍처 패턴처럼 보이지만, 사실은 꽤 새로운 방식이다. 이 아키텍처는 컨테이너와 컨테이너 클러스터를 이용할 수 있지만, 이를 다수의 서로 다른 퍼블릭 클라우드에 페더레이티드 호스트로 배치한다.

몇 가지 조건도 필요하다. 우선은 쿠버페드(Kubefed) 같은 표준과 이를 기반으로 컨테이너 클러스터 페더레이션을 사용하는 제품이 시장이 나와야 한다. 둘째, 클라우드 커뮤니티가 이 아키텍처를 바람직한 것으로 받아들이고, 관련 생태계가 형성되어야 한다. 

물론 현재는 어느 것도 준비되어 있지 않다. 이 방식은 멀티클라우드를 향한 또 하나의 아키텍처를 찾아 기존 방식을 버린다는 의미이다. 이기종 클라우드 네이티브의 문제를 살펴보면, 복잡성과의 싸움이 벌어지고 있음을 알 수 있다. 이 문제를 해결하는 논리적인 방법은 보안이나 거버넌스, 관리, 모니터링, 심지어 데브옵스와 툴체인 같은 공통 서비스를 계획하고 개발하는 것이다.

논쟁은 계획 부족(이기종 네이티브)과 계획 과잉(이기종 페더레이션)의 중간에 있으며, 컨테이너나 쿠버네티스 같은 구체적인 표준 구현 기술의 사용을 강제하지도 않는다. 과연 어떤 아키텍처가 이길까? 이기종 클라우드 네이티브와 그 복잡성을 제거하기만 한다면, 어느 쪽이든 모두 좋을 것이다. editor@itworld.co.kr


X