프라이빗 클라우드는 다른 사고방식을 요구합니다

클라우드는 아무것도 바꾸지 않습니다. 클라우드는 모든 것을 바꿔 놓습니다. 프라이빗 클라우드는 둘 다 하지 않고 둘 다 하지 않습니다.

좋아요, 선(禪)은 이제 그만하겠습니다. 사실, 어떤 형태이든 프라이빗 클라우드에서 실행되는 애플리케이션은 여전히 네트워크가 전통적으로 제공해 온 중요한 애플리케이션 전송 서비스, 즉 보안, 부하 분산, 고가용성 및 최적화가 필요합니다. 마이크로서비스 나 컨테이너 플랫폼과 같은 최신 아키텍처조차도 익숙한 방법을 사용하여 애플리케이션을 계속 실행합니다. 최신 언어나 개발 기술도 액세스 제어 및 웹 애플리케이션 방화벽과 같은 보안 도구로 백업해야 합니다. 이런 식으로는 아무것도 변하지 않습니다.

그럼, 무엇이 문제일까요?

대부분의 조직에서 프라이빗 클라우드는 배포 대상을 바꾸는 것이 아니라 배포 방법, 그리고 더 중요하게는 얼마나 빨리 배포할 수 있는가를 바꿉니다. 성공적인 프라이빗 클라우드 구현은 셀프 서비스 IT를 제공하고 내부 고객이 자동화 및 인프라를 코드로 사용하여 매우 동적이고 운영 효율적인 애플리케이션 환경을 구축할 수 있도록 합니다. 새로운 서비스나 애플리케이션이 더욱 효율적으로 개발되고 제공됨에 따라 코드와 인프라의 변경 빈도는 더욱 빨라질 것입니다. '가치 실현 시간'을 단축하는 데 영향을 미치는 요소 중 상당수가 문화적이고 조직적인 측면이 있지만, 인프라가 걸림돌이 되어서는 안 됩니다. 요청부터 구현까지 인간이 지체할 시간은 없습니다. 인프라에 병목 현상이 발생하지 않는다면 자동화 도구가 대부분의 IT 서비스 제공을 제어할 수 있습니다.  

변경 사항을 수동으로 요청, 검토 및 구현하는 티켓 기반의 기존 조직에서 전환하는 경우 이러한 전환은 일상 활동의 많은 부분을 변경하게 됩니다. IT는 구현 중심에서 프레임워크 설계 및 종단 간 서비스 자동화로 전환될 것입니다. 애플리케이션 개발자 또는 애플리케이션 운영(감히 'DevOps'라고 할까요?)이 스택의 나머지 부분과 동일한 방식으로 네트워크 및 애플리케이션 제공 서비스를 프로비저닝할 수 있도록 하는 방법에 대한 고민은 프라이빗 클라우드 플랫폼을 배포하는 데 중심이 되어야 합니다. 동료의 문구를 훔치다: IT 운영은 버튼을 누르는 사람에서 버튼을 만드는 사람으로 전환되어야 합니다.

철학적 측면에서(결국 이 글은 철학적 측면에서 시작되었습니다) 근본적으로 바뀌는 것은 IT 운영이 인프라를 제어하는 방식입니다. 생각해보세요. 인프라를 변경하기 위해 티켓 시스템과 운영 팀이 있었던 이유는 부분적으로 도메인 전문가만 변경 작업을 수행하도록 하여 오류나 잘못된 구성을 방지하기 위한 것이었습니다. IT 운영팀은 모든 버튼에 접근할 수 있었고 요청된 변경 사항을 적용하기 위해 어떤 버튼을 눌러야 하는지 알고 있었으며 프로세스 중에 다른 것은 망가지지 않기를 바랐습니다. 이제는 누구나 자신의 버튼을 직접 누르거나 소프트웨어가 그 일을 대신 해주기를 원합니다. 작업을 위해 만들어지는 논리적 버튼은 누르기에 안전해야 합니다. 이제 운영이 통제력을 발휘합니다. 요청자에게 원하는 것이 무엇인지 알려주기만 하면 되고, 원하는 바를 어떻게 해야 할지 알려주지 않으며, 안전하고 지원 가능한 구성으로 선택 범위를 제한하는 템플릿화된 자동화 시스템을 구축함으로써 IT는 고객에게 자유를 부여하는 동시에 인프라에 대한 제어권을 유지합니다.

이런 변화는 기술적으로나 문화적으로 어려울 수 있지만, 그로 인해 얻는 생산성과 민첩성의 향상은 거기까지 가는 데 따르는 어려움을 보상할 만큼 충분히 큽니다.