2020.12.31

IDG 블로그 | 멀티클라우드 프로젝트를 망치는 2가지 실수

David Linthicum | InfoWorld
어떻게 보면 멀티클라우드는 쉽다. 그저 하나 이상의 퍼블릭 클라우드를 배치하고 관리하면 된다. 하지만 안타깝게도 지금까지 그렇게 간단하지 않았다. 많은 기업이 멀티클라우드 아키텍처를 배치하면서 몇 가지 하지 않아도 될 실수가 계속 저질러지고 있기 때문이다. 약간만 이해한다면, 충분히 피할 수 있는 실수 두 가지를 소개한다.
 
ⓒ Getty Images Bank

클라우드옵스를 염두에 두지 않고 멀티클라우드를 설계하고 구축한다. 많은 기업이 이런 멀티클라우드 아키텍처를 장기적으로 어떻게 관리해야 하는지 명확한 이해없이 두세 곳, 때로는 그 이상의 퍼블릭 클라우드를 배치한다. 

멀티클라우드 배치가 프로덕션 환경으로 옮겨질 때면 엄청난 수의 클라우드 서비스가 된다. 여러 퍼블릭 클라우드에서 리던던시를 위한 서비스를 이용하면서 생겨난 것들로, 클라우드옵스팀이 모두 처리하기에는 너무 많다. 클라우드옵스팀은 이 모든 서로 다른 클라우드 서비스를 운영하지도 못하고 운영해서도 안되며, 서비스 품질도 엉망이 된다. 보안과 거버넌스 관점에서도 이런 배치는 너무 위험한 방법이 아닐 수 없다. 

이런 실수를 피하는 방법이 있다. 우선, 운영상 필요조건을 기꺼이 갖출 생각이 없다면, 멀티클라우드를 하지 않는 방법이 있다. 단일 클라우드 배치를 고수하는 것이 좋다. 물론 이렇게 하면 최고의 서비스만 골라 쓸 수 없고, 클라우드의 가치도 줄어든다. 올바른 접근법은 거의 모든 것을 자동화하고 추상화를 이용해 복잡성을 관리하는 것이다.

모든 것을 클라우드 네이티브로 선택한다. 여러 퍼블릭 클라우드에 걸쳐 사용할 수 있는 툴이 가장 유용하다는 것을 잊지 말기 바란다. 한 클라우드에서 사용하는 인터페이스와 자동화를 멀티클라우드 환경의 다른 클라우드에서도 사용할 수도 있다.

더 이상 확실할 수 없는 선택 같지만, 멀티클라우드로 이전하는 많은 기업이 특정 퍼블릭 클라우드가 제공하는 네이티브 툴을 고수하고 있다. 특정 퍼블릭 클라우드를 위한 관리 및 모니터링 툴을 선호하는 기업은 각각의 퍼블릭 클라우드마다 다른 툴을 배우고 이용해야 한다. 효율적이지 않다. 각각의 툴을 알고 있는 사람이 있어야 하고, 클라우드 간의 커뮤니케이션이나 조정도 안된다. 자동화 역시 하나가 아니라 여러 클라우드에서 이루어져야 한다. 

이 문제를 피하는 방법은 간단하지만 실행하기는 어렵다. 해법은 전체 클라우드에 사용할 수 있는 툴을 찾아 일관성 있는 인터페이스를 제공하는 것이다. 

멀티클라우드는 아직도 진화 중인 기술이다. 퍼블릭 클라우드 서비스 업체는 좋은 지침과 툴을 제공하지 않으려 한다. 사실 이들 업체에 멀티클라우드는 최고의 관심사가 아니다. 만약 퍼블릭 클라우드 서비스 업체가 복잡성과 비용, 위험성이 증가할 수 있는 설계 패턴을 제시한다면, 피해야 한다. editor@itworld.co.kr


2020.12.31

IDG 블로그 | 멀티클라우드 프로젝트를 망치는 2가지 실수

David Linthicum | InfoWorld
어떻게 보면 멀티클라우드는 쉽다. 그저 하나 이상의 퍼블릭 클라우드를 배치하고 관리하면 된다. 하지만 안타깝게도 지금까지 그렇게 간단하지 않았다. 많은 기업이 멀티클라우드 아키텍처를 배치하면서 몇 가지 하지 않아도 될 실수가 계속 저질러지고 있기 때문이다. 약간만 이해한다면, 충분히 피할 수 있는 실수 두 가지를 소개한다.
 
ⓒ Getty Images Bank

클라우드옵스를 염두에 두지 않고 멀티클라우드를 설계하고 구축한다. 많은 기업이 이런 멀티클라우드 아키텍처를 장기적으로 어떻게 관리해야 하는지 명확한 이해없이 두세 곳, 때로는 그 이상의 퍼블릭 클라우드를 배치한다. 

멀티클라우드 배치가 프로덕션 환경으로 옮겨질 때면 엄청난 수의 클라우드 서비스가 된다. 여러 퍼블릭 클라우드에서 리던던시를 위한 서비스를 이용하면서 생겨난 것들로, 클라우드옵스팀이 모두 처리하기에는 너무 많다. 클라우드옵스팀은 이 모든 서로 다른 클라우드 서비스를 운영하지도 못하고 운영해서도 안되며, 서비스 품질도 엉망이 된다. 보안과 거버넌스 관점에서도 이런 배치는 너무 위험한 방법이 아닐 수 없다. 

이런 실수를 피하는 방법이 있다. 우선, 운영상 필요조건을 기꺼이 갖출 생각이 없다면, 멀티클라우드를 하지 않는 방법이 있다. 단일 클라우드 배치를 고수하는 것이 좋다. 물론 이렇게 하면 최고의 서비스만 골라 쓸 수 없고, 클라우드의 가치도 줄어든다. 올바른 접근법은 거의 모든 것을 자동화하고 추상화를 이용해 복잡성을 관리하는 것이다.

모든 것을 클라우드 네이티브로 선택한다. 여러 퍼블릭 클라우드에 걸쳐 사용할 수 있는 툴이 가장 유용하다는 것을 잊지 말기 바란다. 한 클라우드에서 사용하는 인터페이스와 자동화를 멀티클라우드 환경의 다른 클라우드에서도 사용할 수도 있다.

더 이상 확실할 수 없는 선택 같지만, 멀티클라우드로 이전하는 많은 기업이 특정 퍼블릭 클라우드가 제공하는 네이티브 툴을 고수하고 있다. 특정 퍼블릭 클라우드를 위한 관리 및 모니터링 툴을 선호하는 기업은 각각의 퍼블릭 클라우드마다 다른 툴을 배우고 이용해야 한다. 효율적이지 않다. 각각의 툴을 알고 있는 사람이 있어야 하고, 클라우드 간의 커뮤니케이션이나 조정도 안된다. 자동화 역시 하나가 아니라 여러 클라우드에서 이루어져야 한다. 

이 문제를 피하는 방법은 간단하지만 실행하기는 어렵다. 해법은 전체 클라우드에 사용할 수 있는 툴을 찾아 일관성 있는 인터페이스를 제공하는 것이다. 

멀티클라우드는 아직도 진화 중인 기술이다. 퍼블릭 클라우드 서비스 업체는 좋은 지침과 툴을 제공하지 않으려 한다. 사실 이들 업체에 멀티클라우드는 최고의 관심사가 아니다. 만약 퍼블릭 클라우드 서비스 업체가 복잡성과 비용, 위험성이 증가할 수 있는 설계 패턴을 제시한다면, 피해야 한다. editor@itworld.co.kr


X