2017년 애플리케이션 제공 현황: 자동화, API 및 DevOps

지난해부터 디지털 트렌드가 더욱 가속화되면서 소비자와 기업 사용자에게 앱을 제공하는 네트워크와 인프라를 담당하는 사람들은 DevOps가 제공하는 자동화와 보다 민첩하고 협력적인 관점을 모색하게 되었습니다. 하지만 조직이 자동화를 받아들이고 프로그래밍 가능성(API 및 템플릿)의 중요성을 인식하더라도 모든 것을 지배할 단일 스택에 안주할 준비가 되어 있지는 않습니다.

앱 개발자부터 CEO, 보안 및 네트워크 엔지니어에 이르기까지 IT의 모든 직종에 걸쳐 2,100명이 넘는 응답자를 대상으로 실시한 2017년 애플리케이션 제공 현황 설문 조사에서 DevOps가 프로덕션으로 더욱 이동함에 따라 이를 촉진하는 요인과 인식도 변화한다는 사실을 발견했습니다.

01 | 자동화 도입

디지털 혁신에는 기업용 API와 수많은 개발자만으로는 부족합니다. 우리는 기업이 성장에 맞춰 효율적으로 확장할 수 있도록 하는 데 필요한 내부 변화에 더 많은 관심을 기울이고 있습니다. 더 많은 사람을 업무에 투입하는 것은 더 이상 기업 운영을 확장하는 실행 가능한 수단이 아닙니다. 일을 처리하는 것만이 문제가 아니라 빠르고 효율적으로 일을 처리하는 것도 문제이기 때문입니다.

즉, 관리해야 할 시스템, 사물, 앱이 더 많아지고 위협도 더 많아지고 ID도 더 많아진다는 뜻입니다. IT 내부에서도 이러한 수요를 충족하기 위한 확장 노력이 계속되고 있으며, 이에 대한 대응으로 자동화와 오케스트레이션이 점차 늘어나고 있습니다.

2016년 애플리케이션 제공 현황 설문조사에 참여한 응답자 중 단 21%만이 하나 이상의 자동화 프레임워크를 사용하고 있었습니다. 1년 후에는 그 비율이 52%로 늘어났고, 절반 이상이 두 개 이상의 시스템을 동시에 사용했습니다.  모든 시스템이 성장을 이루었으며, Cisco, OpenStack , VMware가 각각 19%, 14%, 22%로 가장 큰 성장을 보였습니다. 네트워크 및 앱 서비스 자동화가 중요하다는 점을 증명하듯이, 응답자의 35%가 Cisco ACI를 사용하고 있습니다. VMware나 OpenStack과 같은 주요 기술에 비해 상대적으로 새로운 기술이라는 점을 감안하면, 단 2년 만에 상당한 진전이 이루어진 셈입니다.

02 | 하이브리드 스택 규칙 생산

응답자의 39%는 인프라와 앱 서비스를 자동화하는 데 하나의 시스템만 사용하는 반면, 대부분(61%)은 두 개 이상을 사용합니다. 조직이 클수록(그리고 당연히 관리하는 애플리케이션이 많을수록) 그 숫자도 커진다는 점에 유의하세요. 사용 중인 자동화 시스템의 평균 수는 1.8개이지만, 3,000개 이상의 애플리케이션을 관리하는 경우 평균 2.43개가 될 것으로 예상할 수 있습니다.

주목할 점은 사용 중인 클라우드 모델의 평균 수가 1.8개라는 점입니다. 일부 조직에서는 자동화가 클라우드 컴퓨팅의 도입 및 사용에만 국한될 가능성이 매우 높습니다.

이는 오랫동안 VMware에 의존하여 컴퓨팅 인프라를 가상화해 온 기업에 매우 적합합니다. 조직이 기존 자동화를 제거하여 컴퓨팅 프로비저닝과 관리를 강화해야 할 이유는 사실상 전혀 없습니다(정말 죄송합니다). 답은 대개 Cisco ACI와 같은 추가 시스템에서 찾을 수 있습니다. 이는 네트워크 및 앱 서비스 인프라에 대한 프로비저닝 및 관리 자동화를 확장합니다.

단일 자동화 프레임워크에 의존하는 사람 중 거의 절반(47%)이 VMware를 선택했습니다. Cisco는 단 하나의 프레임워크만 사용하는 응답자가 26%인 반면, OpenStack은 9%를 차지했습니다.

7%는 자동화와 오케스트레이션을 실현하기 위해 Python 스크립트에만 의존하는데, 이는 네트워크 및 앱 서비스 플랫폼 API를 중심으로 강력하고 잘 지원되는 고객 중심 커뮤니티가 필요하다는 것을 의미합니다.  

03 | 속도보다 확장

DevOps의 가장 자주 언급되는 이점은 속도입니다. 성공 여부를 측정하는 데 사용되는 지표는 배포 빈도와 출시 시간을 중심으로 구성됩니다. 그러나 네트워크 및 앱 서비스 인프라와 관련해서는 확장성이 자동화와 오케스트레이션의 원동력이 됩니다. 응답자 중 단 14%만이 자동화 프레임워크 사용의 동인으로 출시 기간을 꼽았고, 도입 이유로는 규모(37%)와 운영비 절감(37%)을 꼽았습니다.

우리는 OpEx 감소가 "예산 유지"를 위한 코드라고 생각합니다. Computer Economics의 최신 조사에 따르면 IT 예산은 거의 움직이지 않거나 정체되어 있기 때문에 예산 최적화가 의심할 여지 없이 중요한 관심사입니다. 이미 상당한 장치 대 엔지니어 비율을 감안할 때, 더 많은 직원을 추가하지 않고 확장하는 것은 어렵기 때문에 자동화와 오케스트레이션은 운영 예산을 크게 늘리지 않고도 확장할 수 있는 한 가지 방법입니다.

자동화가 배포 속도를 향상시키는 데 영향을 미치는 경우가 많다는 점이 흥미롭습니다. 배포 프로세스를 조율하기 위한 첫 번째 단계로 가치 스트림을 매핑할 때 배포 지연을 유발하는 "대기 시간"을 쉽게 찾을 수 있습니다. 이러한 대기 시간은 종종 팀 간의 핸드오프이거나 엔지니어가 특정 작업을 수행하기 위해 시간을 낼 때까지 기다리는 "대기 시간"입니다. 자동화를 통해 대기 시간과 줄을 서는 시간을 줄일 수 있으며, 이를 통해 전체 프로세스 속도를 높이고 제품 출시 시간을 단축할 수 있는 이점이 있습니다.

SDN 동인을 살펴보면 비슷한 사실을 알 수 있습니다. 62%가 운영 비용을 줄이기 위해 SDN을 도입했습니다.

04 | 프로그래밍 가능성이 중요합니다

소프트웨어로 모든 것을 정의하는 것이 일반화되기 오래전, 프로그래밍 기능을 통해 제품을 통합하여 고객에게 더욱 포괄적인 기능을 제공할 수 있는 수단을 제공함으로써 공급업체 간 생태계가 가능해졌습니다. 동일한 API는 이제 다른 API 경제로 발전하여 다양한 기능과 역량을 고객에게 직접적으로 제공하고 오픈 소스 시스템과의 광범위한 통합을 장려합니다.

클라우드 또는 데이터 센터 바운드 인프라와 관련이 있든, 프로그래밍 가능성은 네트워크와 앱 인프라가 자동화되고, 프로세스가 오케스트레이션되고, 궁극적으로 확장이 달성되는 방식입니다. 프로그래밍 가능성은 API와 연관되는 경우가 가장 많고, 템플릿 개념과 연관되는 경우가 점점 늘고 있습니다. 우리 조사에서 두 가지 모두 인식된 중요성에서 극적인 급증을 보였으며, 대다수가 두 가지 모두 인프라에 있어 "더 중요한" 특성으로 지정했습니다.  

데이터 경로 프로그래밍 기능은 잘 이해되지 않고 논의되지도 않습니다. 즉, 비행 중인 데이터를 가로채고, 검사하고, 수정할 수 있는 기능입니다. 이를 통해 URL 다시 쓰기, 쿠키 보안, HTTP 헤더 추가/제거와 같은 애플리케이션 계층 기능은 물론, 보안에 적합한 프로토콜에 대한 심층적인 검사(특히 새로운 익스플로잇에 대응)가 가능해집니다.

놀랍게도 이 기능은 API나 템플릿보다 "더 중요한" 것으로 간주됩니다. 응답자의 52%는 API를 "더 중요하다"고 생각하고 53%는 템플릿을 "더 중요하다"고 말하며, 57%는 데이터 경로 프로그래밍 기능을 "더 중요하다"고 태그합니다.

특히 보안 분야에서 민첩성 측면에서 데이터 경로 프로그래밍이 제공하는 비즈니스 이점은 응답자들이 이러한 기능을 도입하는 데 충분한 동기를 제공합니다.

프로그래밍, 자동화 및 오케스트레이션은 사라지지 않을 것이며, 앱 개발자 외의 상당수의 역할이 이러한 개념을 수용하는 것을 보는 것은 고무적입니다. 자동화, 오케스트레이션 및 관련 개념을 예산 및 규모와 같은 과제를 해결하기 위한 전술적 대응책으로 볼 수 있지만, 그들은 확실히 DevOps라는 뷔페에 참여하여 기업의 디지털 전환을 내부와 외부에서 가능하게 하는 데 필요한 공중 엄호를 제공하고 있습니다.

SlideShare에서 슬라이드 형식의 데이터를 자유롭게 살펴보세요.