모든 기술 트렌드에는 너무 과장되어 사실상 쓸모가 없어질 수 있는 용어가 항상 있습니다. 처음에는 클라우드도 그 중 하나였습니다. 어떤 면에서는 아직도 그렇죠. DevOps를 정리하는 데는 몇 년이 걸렸습니다(정리했을지도 모르지만요). 머신러닝과 AI는 현재 과대광고의 물결을 맨발로 타고 있으며, 조만간 사라질 조짐은 보이지 않습니다.
그 바로 뒤에는 "코드로서"가 있습니다.
갑자기 모든 것이 "코드"로 표현되었습니다. 시장에서는 "코드형" 언어에 대한 열풍이 식지 않고 있습니다. 대부분이 C, C++, C#의 차이를 알아채지 못하더라도요. "코드로서"는 삶과 우주, 그리고 모든 것에 대한 답이 되었습니다. "코드로" 해결할 수 없는 문제는 없으며, 모두가 그렇게 하고 있습니다.
경계나 명확한 정의 없이 용어가 난무할 때, 우리는 잠시 멈추어 *우리*의 정의를 명확히 하는 것이 중요합니다. RFC 스타일의 정의를 참조할 수 있는 표준 위원회가 있으면 좋겠지만, 그런 위원회는 없습니다. 우리가 가장 가까이 접한 곳은 NIST이고, 그들이 클라우드 난제를 얼마나 잘 해결하는지 보았습니다.
"코드형 인프라"에는 코드형 인프라(IAC)보다 더 많은 요소가 있습니다. Pythian의 Aiman Najjar가 현재 인프라스트럭처-코드 환경에 대한 훌륭한 개요를 작성했습니다 . 저는 컨테이너가 별도의 계층이 되어야 한다는 의견(네트워크와 애플리케이션 서비스 관점에서 보면 단지 인프라일 뿐)이나 Jenkins가 여기에 속하지 않는다는 의견에는 동의하지 않지만, 전반적으로 그의 블로그는 '코드로' 계층의 관계를 이해하고 적절한 작업에 적절한 도구를 매핑하는 데 있어 훌륭한 방법이었습니다. 또한, 대부분의 코드 기반 인프라에 대한 논의는 지속적인 배포 에 초점을 맞춥니다. 지속적인 배포란 앱을 빌드하고, 테스트하고, 통합하고, 프로덕션에 릴리스하는 파이프라인을 말합니다. 이는 릴리스된 애플리케이션을 필요한 네트워크 및 애플리케이션 서비스와 함께 프로덕션 환경에 배포하는 데 중점을 둔 지속적인 배포 와는 동일한 프로세스가 아닙니다.
참고 앱 유토피아에서는 전달 및 배포 파이프라인이 수렴됩니다. 하지만 우리 대부분은 (여전히) 앱 현실 속에서 살고 있습니다. 즉, 프로덕션과 개발은 서로 다른 환경이며 요구 사항과 제약이 서로 다릅니다. 따라서 파이프라인에 자동화를 적용할 때 이러한 분리를 인식할 필요가 있습니다.
IT와 배포 파이프라인의 고유한 특성을 포괄하는 세 가지 계층이 존재합니다. 그 중 가장 중요한 것은 환경에 내재된 복잡성입니다. 네트워크 다이어그램에서 클라이언트에서 앱으로 이어지는 직선은 누구도 속일 수 없습니다. 다이어그램으로 나타낼 수 있는 시간(과 인내심)보다 훨씬 더 많은 일들이 후드 아래에서 일어납니다.
파이프라인 자체의 다양성(COTS에 배포된 특수 목적 하드웨어와 가상 및 컨테이너 기반 소프트웨어로 구성됨)은 '코드로서' 분할하여 별도의 계층으로 나눌 수 있는 원동력을 제공합니다. 최신 하드웨어는 코드형 접근 방식으로 관리할 수 있지만, 기존(공유) 하드웨어를 이 프로세스에 끼워 넣는 것은 거의 불가능할 수 있습니다. 그런 다음 배포 프로세스 자체를 더욱 긴밀하게 반영하기 위해 계층을 분리하면 파이프라인에 소프트웨어 기반 서비스와 함께 기존 및 최신 하드웨어 기반 솔루션을 모두 포함할 수 있는 방법을 제공할 수 있습니다.
목표는 멀티 클라우드 환경에서 앱별 배포 일정과 아키텍처를 지원할 수 있는 지속적인 IT 스택을 구축하는 것입니다. 배포는 애플리케이션의 활성 수명 주기의 시작일 뿐이므로 배포 후 작업에 중점을 둔 네 번째 계층이 필요합니다. 이는 인프라 프로비저닝 및 온보딩, 서비스 구성 및 관리, 배포 파이프라인을 포함하는 세 가지 핵심 계층에 추가됩니다.
이 도구 목록이 모든 것을 포함하는 것은 아닙니다 . 다른 도구와 도구세트도 많이 있습니다. 예를 들어, 여러 설문 조사와 연구를 통해 대부분의 NetOps는 네트워크 및 애플리케이션 서비스를 자동화하는 작업에 맞춤형 Python 스크립트를 선호한다는 사실을 알 수 있습니다. 또한 Cisco ACI, VMware NSX, OpenStack, Red Hat OpenShift와 같은 네트워크 자동화 시스템과 스택이 지속적인 운영 스택에서 많은 기능을 구현하는 널리 사용되는 수단이라는 사실도 알고 있습니다. 모든 도구를 모두 포함하기에는 시각적 공간이 충분하지 않으므로 DevOps에서 도구의 인기에 따라 샘플링을 포함했습니다. 전달 및 배포 파이프라인 전반에 걸친 표준화가 성공의 필수 구성 요소가 될 것이기 때문에, '코드로' 전달 파이프라인을 구현하는 데 가장 일반적으로 사용되는 도구와 함께 조직 내의 기존 기술과 전문 지식을 활용하는 것에 반대하기 어렵습니다. 주목할 점은 "코드로서의 작업"을 위한 도구는 나열하지 않았다는 점인데, 이 중 많은 도구가 맞춤형(사용자 정의 스크립트)이거나 특정 공급업체 기술에만 국한되어 있기 때문이다. 적어도 지금으로서는 그렇다.
참고 코드로서의 운영은 비즈니스 프로세스 관리(BPM)와 동등한 IT 시스템입니다. BPM을 사용하면 비즈니스 프로세스가 자동화됩니다. 일부 BPM은 매우 구체적인 워크플로우에만 초점을 맞추고, 다른 BPM은 구매에서 결제, 배송까지 고객 상호작용의 길이와 범위를 포괄할 수 있습니다. 오늘날 IT 분야에서 코드형 운영은 새로 생겨나는 관행이지만, 기업이 BPM을 활용하는 방법을 익힌 것과 같은 방식으로 최적화된 운영 프로세스를 활용하려면 운영 프로세스 관리로 성숙해야 합니다.
클라우드든 데이터 센터든 여전히 구성이 필요한 네트워크가 있습니다. 더 높은 순위의 서비스(4~7계층에서 작동하는 애플리케이션 서비스)라도 작동하려면 네트워크 토폴로지에 대한 지식이 필요합니다. 새로운 파이프라인을 배포하는 경우 일부를 활성화(즉, 라이선스)해야 할 수도 있습니다. 셀프 서비스 방식의 배포를 위해서는 Infrastructure as Code가 필요합니다. 인프라(소프트웨어와 서비스)가 없으면 앱을 구성하거나 배포할 대상이 없기 때문입니다.
책임: 인프라 온보딩, 라이선싱, 프로비저닝
이는 구성과는 별개의 문제입니다. 구성은 해당 서비스에 맞는 정책과 동작을 구성해야 할 필요성을 구체적으로 나타냅니다. 구성은 주요 애플리케이션 업데이트마다 반복될 수 있습니다. 모든 사소한 업데이트마다 반복될 수도 있습니다. 보안 관련 서비스의 경우, 해당 서비스를 패치, 업데이트 또는 업그레이드하는 일이 비상 상황에 발생할 수 있습니다. 코드로 구성하는 것은 앱별 배포 일정과 파이프라인을 지원하고 프로덕션 파이프라인 전체의 안정성을 보장하는 데 중요한 애플리케이션 데이터 경로의 격리를 시행하는 데 중요합니다.
책임: 서비스 구성, 업그레이드 및 패치
그리고 처음부터 끝까지 전체 애플리케이션과 서비스를 정의하는 포괄적인 프로세스가 있습니다. 이는 전체 파이프라인이며, 배포를 자동으로 구동하는 실행 가능한 프로세스로 체계화됩니다. 코드로서의 파이프라인은 IaC와 CaC를 연결하여 배포 파이프라인이라고 부르는 것을 설명합니다. 가장 큰 속도와 효율성 향상은 파이프라인에서 찾을 수 있는데, 이를 통해 프로세스에 필요한 각 단계 사이의 대기 시간을 없앨 수 있기 때문입니다.
책임: 배포 프로세스 자동화
이 계층은 지속적으로 운영되는 계층입니다. 모니터링, 알림, 자동 크기 조정, 검색이 이루어지는 곳입니다. 이 계층에서 우리는 운영 프로세스를 스스로 실행할 수 있는 시스템으로 체계화하는 데 관심을 둡니다. 자동 확장은 가장 자주 체계화된 운영 프로세스 중 하나이며 여러 시스템이 포함됩니다. 하지만 분석을 위해 원격 측정 데이터를 수집하는 것은 주의가 필요한 또 다른 운영 프로세스이며, 데이터 경로나 애플리케이션 성능을 최적화하기 위한 (자동) 조정을 가능하게 하는 원격 측정 데이터를 기반으로 수행할 수 있는 작업도 주의가 필요합니다. 이러한 운영 프로세스는 자체 구성을 가지며 배포 프로세스가 완료된 후 실행됩니다.
책임: 운영 워크플로 자동화
지속적인 운영 스택의 관점에서 지속적인 배포를 살펴보면 생산 파이프라인을 자동화하는 전략적 접근 방식을 얻을 수 있습니다. 계층과 책임을 분리함으로써 많은 조직에서 원하고 기업에서 점점 더 요구하는 셀프 서비스 방식을 구현하는 방식으로 IT 업무를 자동화하는 엄청난 작업에 더 쉽게 접근할 수 있습니다. 또한 IT 내에서 자동화를 활용하는 데 있어 필수적인 발전인 코드형 운영을 통해 지속적인 운영으로 이어질 수 있는 경로도 제공합니다.
하지만 이는 배포 파이프라인과 관련된 자동화 작업을 보는 '유일한 진정한 방법'이 아닐 수도 있습니다. 하지만 이는 한 가지 방법이며, 시장이 자신들이 하는 일과 하지 않는 일을 명확하게 말할 수 있는 능력을 제공합니다.
즉, 특히 F5 제품과 관련하여 인프라를 코드로 제공 하거나 구성을 코드로 제공한다고 말할 때 제가 의미하는 바를 확실히 알 수 있다는 의미입니다.