관리 ≠ 오케스트레이션

네트워크와 보안과 같은 나머지 IT에 애자일 방법론의 파장 효과가 계속되는 것을 보면서 SDN 및 SDDC와 같은 아키텍처와 기술이 부상하는 것을 보았고, DevOps가 인접 IT 문제로 계속 확장되는 것도 보았습니다.

그 이유는 앱에 대한 소비자의 욕구만큼이나 (배포) 속도에 대한 필요성이 커지고 있기 때문입니다. 오늘날 기업의 성장은 IT의 확장 능력에 달려 있습니다. 이는 거래 속도나 처리량뿐만 아니라 운영적인 면에 있어서도 중요합니다.

빠르고 예측할 수 없는 수요를 지원하는 데 필요한 규모를 달성하려면 더 많은 하드웨어(맞춤형이든 COTS든)와 더 많은 플랫폼, 더 많은 서비스, 그리고 모든 것이 필요합니다. 모니터링, 백업, 구성 및 라이선스가 필요한 사항이 더 많습니다. 그것이 경영이에요.

앱과 전송 서비스를 배포하는 데 필요한 속도를 달성하려면 배포 프로세스를 자동화해야 합니다. 그것이 오케스트레이션이에요.

이 둘은 같지 않습니다. 사실, 이 둘을 혼동하는 것은 위험한 일입니다. 둘을 혼동하면 두 가지가 서로 밀접하게 결합되어 프로세스를 빠르게 변경하기 어려워지기 때문입니다. 이는 생산성과 수익을 위해 기업이 의존하는 앱의 성능, 속도 및 보안을 유지하는 데 필요한 구성 요소를 시스템에 추가하거나 효율성을 개선하는 데 종종 필요합니다. 그건 일년에 여러 번 일어날 수 있어요. 비즈니스 프로세스 관리 전문가들은 연구를 통해 기업이 핵심 프로세스를 1년에 4~7회 변경한다고 말합니다. 그들은 소비자와 기업 사용자의 피드백과 더불어 IT 부서가 수집한 모든 데이터를 분석하여 이를 수행합니다.

2000년대 중반부터 비즈니스 계층에서 그러한 민첩성을 보장하기 위해 비즈니스 프로세스 오케스트레이션(BPO)이 필수가 되었습니다.

그리고 이제 우리는 IT 계층에서도 그것을 보고 있습니다.

비즈니스 성공에 필요한 규모와 속도의 배포를 실현하고자 하는 모든 조직의 성공적인 변혁을 위해서는 운영 프로세스 조율이 매우 중요합니다.

하지만 그렇다고 해서 경영이 중요하지 않다는 것은 아닙니다.

여전히 관리가 필요하며 특정 관리 작업은 자동화될 수 있고(종종 자동화되어야 함) 오케스트레이션은 아닙니다. 중요 시스템의 자동 야간 백업, 업그레이드, 라이선스 관리, 패치, 심지어 자산 관리(인벤토리)는 IT가 운영상 확장을 보장하고 단일 관리자가 점점 더 많은 장치를 관리할 수 있도록 하는 중요한 수단이지만, 이는 오케스트레이션이 아닙니다.

반대로, 오케스트레이션은 관리가 아닙니다. OpenStack , Cisco ACI, VMware NSX 와 같은 오케스트레이션 엔진(시스템, 프레임워크 등 뭐라고 부르든)을 사용하면 특정한 이점을 얻을 수 있지만, 이러한 엔진 중 어느 것도 프로비저닝되는 실제 구성 요소의 핵심 관리를 활성화하지 못합니다. 예를 들어, LBaaS를 제공하기 위해 BIG-IP를 만들고 시작할 수는 있지만 실제로 해당 인스턴스를 관리하는 사업은 아닙니다. 업데이트를 실행하지 않고, 핫픽스를 적용하지 않고, 알림을 확인하지 않고, 일상적인 업무 중 어떤 것도 수행하지 않으며, 기업의 지속적인 운영을 보장하는 데 필요한 책임을 맡지 않습니다. 그건 관리의 임무이지 조율의 임무가 아닙니다.

둘은 동일하지는 않지만 애플리케이션 세계에서는 둘 다 똑같이 중요합니다. 오케스트레이션은 IT가 앱 배포를 확장할 수 있도록 하여 비즈니스를 확장할 수 있게 하고, 경영진은 클라우드 덕분에 잊고 있는 모든 작업을 처리하여 비즈니스가 계속 운영되도록 보장합니다. 

경영진은 셀프 서비스 프로비저닝 및 배포를 활성화하여 오케스트레이션을 수행(협업)하지만 이 둘은 동일하지 않습니다. 그래서는 안 됩니다.