컨테이너 랜드에서는 선언적 구성이 왕입니다.

내부의 디지털 전환은 외부의 디지털 전환을 가능하게 하는 데 필수적입니다. 내부 디지털 혁신의 기본 구성 요소 중 하나는 제어 평면 에 크게 의존하는 자동화입니다. 자동화는 제어 평면에서 발생합니다. 옛날 컴퓨팅 시대에는 이를 "관리 네트워크"라고 불렀고 SNMP와 같은 프로토콜을 사용하여 모니터링, 구성 및 제어를 제공했습니다.

오늘날에도 관리 네트워크는 여전히 존재하며, 적어도 이론적으로는 제어 평면을 통해 동일한 작업을 수행하는 매체로 사용됩니다. 제어 평면은 복잡한 분산 시스템의 개별 구성 요소가 (거의) 자동으로 자체 관리될 수 있도록 하는 API, 마스터 노드, 심지어 메시지 큐로 구성된 복잡한 영역입니다. 점점 더 이벤트 중심적이 되어가고 있으며, 과거 명령형 관리 모델에 주로 의존했던 중앙집중적 명령 및 통제 모델에서 사고방식의 변화가 필요합니다. 즉, 중앙 시스템은 특정 API 호출을 통해 구성 요소에 암묵적으로 지시를 내려 변경이 발생하도록 합니다. 반면, 오늘날의 환경은 스스로를 변화시킬 책임을 분배하는 선언적 모델에 의존합니다.

컨테이너화된 환경보다 이 사실이 더 확연하게 드러나는 시스템은 없습니다. 외부에서 볼 때, 이런 시스템은 본질적으로 거의 사기적인 것처럼 보인다. 메시지와 이벤트는 마음대로 공개되고 발사되며, 이에 누가 또는 무엇이 반응해야 하는지 지시할 수 있는 지배자가 없다. 제어 평면은 더 이상 제어에 관한 것이 아니라 허브 앤 스포크 아키텍처의 구식 관리 시스템보다는 메시에 가까운 평면에 분산하는 것입니다. 기존 환경에서는 API와 프로토콜을 사용하여 구성 요소에 변경 사항을 적용했습니다. 디지털 컨테이너화된 세계에서는 API를 사용하여 구성 요소가 자체를 변경하는 데 필요한 정보를 가져옵니다.

이 새로운 세상은 반응형이며 기존 제어 평면의 명령형(API 기반) 모델을 피하고 대신 더 개방적이고 선언적인 모델을 사용하여 원하는 자동화된 최종 상태를 달성합니다.

이는 놀라운 일이 아닙니다. 우리는 모든 것에 소프트웨어 중심 접근 방식(DevOps, 클라우드, NFV의 틀 아래)을 점점 더 많이 도입하면서 동시에 엄청난 운영 규모를 처리해야 했습니다. 허브 앤 스포크 방식의 필수형 관리 모델은 모든 변경에 대한 부담이 거의 무한한 구성 요소 그룹과 혼란스러운 API를 통해 통신할 수 있는 중앙 컨트롤러에 있으므로 효율적으로 확장할 수 없습니다. 이는 관리자(컨트롤러)가 영향을 받는 각 구성 요소에 변경 사항을 푸시하는 "푸시" 모델입니다. 이는 전체 시스템을 성공시키거나 실패하게 만드는 병목 현상이 됩니다.

구성 요소를 끌어오는 이벤트 기반 모델은 확장하고 컨트롤러의 부담을 덜어주는 데 필요하며, 이를 위해서는 이 제어 평면에 참여하려는 구성 요소가 선언적 구성 모델에 익숙해야 합니다. API를 통해 변경 사항을 푸시하는 대신(필수), 컨테이너는 선언적 구성을 통해 변경 사항을 풀하도록 푸시합니다. 변경 사항을 올바르게 구독하고 해당 변경 사항을 즉시 구현하는 데 필요한 적절한 정보를 가져오는 것은 구성 요소 제공자(오픈 소스 또는 상업용)의 책임입니다.

이것이 코드로서의 인프라처럼 들린다면 그럴 것입니다. 선언적 구성은 기본적으로 코드이거나 적어도 코드 아티팩트입니다. 자동화는 구성을 서비스에서 분리한다는 전제에 점점 더 의존하고 있습니다. 이상적인 유토피아 모델에서는 이러한 선언적 구성은 완전히 불가지론적입니다. 즉, 해당 서비스를 지원하는 모든 공급업체(상업용 또는 오픈 소스)의 모든 제품에서 읽을 수 있습니다. 예를 들어, 적절한 서비스(가상 서버)와 해당 리소스 풀을 손상시키는 앱을 설명하는 선언적 구성은 서비스 X 또는 서비스 Y에서 수집되어 구현될 수 있습니다.

쿠버네티스 리소스 파일은 원하는 것이 기술되어 있지만 어떻게 해야 할지에 대한 규정은 없는 선언적 구성 모델의 좋은 예입니다. 이는 구현 시 원하는 결과를 달성하는 방법 을 잘 알고 있어야 하는(때로는 아주 자세하게) 인프라 API에 의존하는 시스템과는 현저히 다릅니다.

선언적 모델을 사용하면 인프라를 가축처럼 다룰 수 있는 기능도 제공됩니다. 하나가 실패하면, 그것을 종료하고 새로운 인스턴스를 시작하는 것은 간단한 일입니다. 필요한 모든 구성은 리소스 파일에 들어 있습니다. 잃을 작업이 없기 때문에 "작업을 저장하지 않으면 사라집니다"라는 버튼이 없습니다. 이는 거의 변경할 수 없고 확실히 일회용 인프라이며, 장애의 영향을 최소화하기 위해 매분, 아니 초 단위로 변경되는 시스템에서는 필수적입니다.

우리가 점점 더 규모와 보안을 갖춘 자동화된 시스템으로 이동함에 따라, 우리는 애플리케이션 데이터 경로를 구성하는 수많은 장치와 서비스를 관리하기 위한 선언적 모델을 받아들여야 할 것입니다. 그렇지 않으면 통합 및 자동화의 수동적 방법에서 발생하는 엄청난 운영 부채에 파묻힐 위험이 있습니다.