API는 통합이 아닙니다. 이는 통합을 구현하는 수단입니다. ITOps에서 언급된 과제를 살펴보면 IT가 지속 가능하게 운영되기에 충분하지 않습니다.
애플리케이션 개발 분야에서 통합은 언제나 중요한 개념이었습니다. DLL에서 공유 라이브러리, ESB에서 메시지 큐에 이르기까지 우리는 애플리케이션을 다른 앱과 서비스와 통합하는 수많은 수단을 모색해 왔습니다.
네트워크 관리 분야에서는 특히 중요했습니다. 통합은 애플리케이션을 제공하고 보호하는 네트워크 장치와 애플리케이션 서비스의 여러 공급업체가 서로 다른 방식으로 협력하는 파이프라인에 내재된 복잡성을 관리하는 데 중요한 요소였습니다.
오늘날 해당 파이프라인은 점점 더 자동화되고 있습니다. 개발자와 DevOps는 통합 과제를 성공적으로 극복하여 지속적인 개발 파이프라인을 구축했습니다. 이제 그들은 IT 부서가 배포 파이프라인에서도 동일한 조치를 취하기를 기대하고, 아니, 요구합니다.
IT가 대응 중입니다. " NetOps Meets DevOps"에 따르면: 네트워크 자동화의 현황 "에 따르면, 생산 파이프라인의 상당 부분이 최소한 부분적으로 자동화되었습니다.
하지만 지속적인 배포를 도입하는 데에는 어려움이 따릅니다.
설문조사에서는 일반적으로 '문화'가 DevOps 및 DevOps 관련 관행을 방해하는 최대 요인으로 강조됩니다. 네트워크 자동화 현황 조사에서 문화는 상위 3개 요소 중 하나였습니다. 하지만 그것이 가장 큰 좌절은 아니었습니다. 2위도 차지하지 못했습니다. 그 자리는 기술 격차에 대한 좌절과 제가 가장 좋아하는 네 글자 단어인 통합으로 가득 차 있었습니다.
사실, 이 두 가지 과제는 서로 연관되어 있습니다. 통합이 좌절의 큰 원천이 되는 이유 중 하나는 바로 기술 격차 때문입니다. 그 이유는 NetOps가 - 놀라실지도 모르지만 - 개발자가 아니기 때문입니다.
진짜 문제는 바로 이겁니다. DevOps가 지속적인 배포를 실현하려는 노력에서 큰 성공을 거둘 수 있었던 이유 중 하나는 주로 개발자로 구성되었기 때문입니다. 코드로 살고 숨쉬는 개발자. 그들은 통합이 필요한 것을 통합하는 노하우를 갖고 있습니다. NetOps는 반드시 그런 기술을 갖추고 있지는 않습니다. 배포 파이프라인은 주로 프로토콜을 통해 통합되는 장치와 시스템으로 구성됩니다. 코드 기반 통합이 필요하지 않은, 잘 정의된 RFC 기반 프로토콜입니다. 원래 그렇게 설계되었기 때문입니다.
이는 NetOps에 있어 완전히 새로운 과제이며, 이를 충족할 준비가 되어 있지 않거나 기술이 부족합니다.
API로는 이런 문제를 해결할 수 없습니다. API 기반 인프라는 여전히 중요합니다. 2018년 애플리케이션 제공 현황 설문 조사 에 참여한 응답자의 4분의 3이 이를 중요하다고 답했습니다. 그러나 API는 통합이 아닙니다. 이를 통해 통합이 가능하지만, 서로 다른 장치와 시스템을 관리 콘솔과 제어 장치에 연결하고 연결하는 실제 작업은 여전히 IT 부서의 책임입니다. 반드시 그렇게 하는 데 필요한 기술을 갖고 있지 않은 사람들. 이러한 과제는 배포 파이프라인에 대한 매우 수동적인 접근 방식을 요구하기 때문에 일상 업무에 큰 영향을 미칩니다.
이는 NetOps의 절반 이상(52%)이 사용하는 주로 "CLI/스크립트 기반, 장치별" 관리 방법론을 설명합니다. DevOps와 NetOps가 언급한 여러 공급업체의 조직적인 운영 방식 간의 차이는 엄청났습니다. DevOps의 29%는 여러 공급업체의 오케스트레이션 방식을 사용하는 반면, NetOps의 경우 동일한 방식을 사용하는 비율은 12%에 불과합니다.
이러한 차이는 NetOps 통합에 대한 더 나은 접근 방식과, 통합 과제를 극복하기 위해 커뮤니티와 시장이 쏟는 열렬한 열정에 대한 필요성을 분명히 보여줍니다.
자동화와 오케스트레이션의 새로운 세계를 이해하고 싶다면 무료 온라인 Super-NetOps 프로그램을 확인해 보세요. F5 기술에 자동화와 오케스트레이션을 적용하는 데 중점을 두는 것 외에도 REST API를 사용하고 Postman과 같은 도구를 사용하고 자동화 플레이북을 작성하는 데 필요한 기본 지식도 제공합니다.