우리가 바라는 것은 몇몇 데이터를 입력하면 클라우드 복잡성 순위가 나오는 공식이다. 하지만 말처럼 쉽지 않다. 클라우드 복잡성의 순위를 매기는 데는 많은 요소를 계산해야 하기 때문이다. 워크로드부터 데이터베이스, 스토리지 시스템, 보안 모델, 거버넌스 모델, 관리 플랫폼까지 모든 요소의 수가 영향을 미친다.
이런 구조적 복잡성을 해결하는 대중적인 접근법은 구조적인 원칙을 실천하면 처음에는 시스템이 복잡하지 않다고 말한다. 클라우드 시스템을 단기적으로 구축하고 이전하는 것을 상정한 것으로, 스토리지나 컴퓨트, 보안, 거버넌스와 같은 표준 플랫폼을 거의 고려하지 않고 전력 질주하는 방식이다. 많은 클라우드 마이그레이션과 새로운 개발이 사일로 환경에서 구조적 공통성에 대한 고려없이 진행된다. 이 때문에 복잡성은 불가피한 것이 된다.
한편으로 복잡성이 항상 나쁜 것은 아니다. 대부분 과도한 이종성은 베스트 오브 브리드에 우선순위를 두고 서로 다른 클라우드 서비스를 다양하게 선택했기 때문에 생긴다. 복잡성은 이에 따른 자연스러운 결과이다.
좋은 경험칙은 클라우드 운영이나 클라우드옵스를 고려하는 것이다. 만약 예산 범위 내에서 운영되고 있다면, 서비스 중단이나 규정 위반이 없다면, 복잡성 역시 통제하게 있다고 볼 수 있다. 이들 측정 기준을 분기마다 확인하기 바란다. 만약 모든 것이 계속 잘 운영된다면, 복잡해도 괜찮다. 현재로서는 덜 복잡한 클라우드를 구현한 몇 안되는 행운아 중 하나라고 볼 수 있다.
대다수 기업이 이미 복잡성 문제를 안고 있으며, 2020년 말이면 단절된 클라우드 구축이나 마이그레이션 팀, 또는 멀티클라우드 아키텍처 상의 베스트 오브 브리드 중심 전략 때문에 복잡성 문제를 안게 될 것이다. 보통 이런 접근법의 단점은 우선은 복잡한 클라우드 배치를 유지하는 데 필요한 기술력과 툴, 예산이 부족하다는 것이다. 그리고 나중에는 서비스 중단이나 보안 사고, 그리고 클라우드옵스 인력의 잦은 이직으로 이어질 수 있다.
이런 복잡성을 해결하는 첫 단계는 모든 데이터와 서비스, 워크로드, 플랫폼을 검사하는 것이다. 이들을 추상화와 자동화를 지원하는 툴을 사용해 관리할 수 있는 방법을 찾아보기 바란다. 간단하지 않겠지만, 복잡성을 해결하기 위한 프로세스 자체는 복잡할 수도 있다. editor@itworld.co.kr