NetOps에 대한 최소 실행 가능 배포가 있습니까?

네트워크 자동화는 정말로 전부 아니면 아무것도 아닌가?

네트워크 자동화(생산 파이프라인을 DevOps하는 관행)는 이미 상당수의 조직에서 사용 중입니다. 완전히 참여하는 사람은 거의 없지만 대부분(최신 애플리케이션 제공 상태 에 따르면 77%)은 프로덕션에서 자동화를 시범적으로 실시하거나 부분적으로 사용하고 있습니다.

DevOps와 긴밀하게 연관된 개념 중 하나(따라서 종종 NetOps와 연결됨)는 최소 실행 가능 제품(MVP)이라는 개념입니다.

이는 Agile 방법론의 일부이며, 개발 주기를 단축하고 솔루션을 더 빨리 시장에 출시하는 방법으로 사용됩니다. 그건 우리가 "네트워크"에 절실히 필요로 하는 것입니다. 이전 블로그에서 언급한 Appian 설문 조사를 기억하실 겁니다. 그 조사에 따르면 응답자의 72%가 비즈니스 요구에 맞춰 IT를 확장할 수 있는 자신감이 부족하다고 답했습니다.

아야. IT 분야에서 자동화가 상당히 광범위하게 활용되고 있음에도 불구하고, 개발자와 비즈니스 이해 관계자들은 여전히 우리의 능력에 대한 확신이 부족합니다.

따라서 DevOps의 도구, 기술 및 방법론을 도입하여 더 스마트하게 확장함으로써 작업 속도를 높이는 것은 그렇게 미친 짓이 아닙니다. 하지만 MVP를 네트워크에 적용하는 방법을 알아내기 전에, 먼저 MVP가 무엇인지 이해해야 합니다. DevOps, Agile 또는 MVP에 익숙하지 않은 분들을 위해 Agile Alliance에서 간단히 정의한 내용은 다음과 같습니다. 

이 글에서 저는 DevOps(및 관련 기술 및 방법론)와 관련된 많은 개념이 NetOps 이니셔티브에 적용 시 항상 잘 변환되는 것은 아니라는 점을 언급합니다. 실험이라는 용어는 엔지니어, 건축가 또는 IT 임원이 네트워크를 변경하는 것에 대해 논의할 때 사용하는 용어가 아닙니다.

폭발 반경이 이렇죠. 규모가 크고 책임감이 강해요. 대부분의 조직은 운영상 위험을 크게 허용하지 않는데, 그럴 만한 이유가 있습니다. 정전은 실제로 비용을 초래하고 때로는 일자리를 앗아갑니다. 네트워크는 실제로 실험을 하기에 적합한 곳이 아닙니다.

하지만 그렇다고 해서 NetOps에 대한 최소 실행 가능 배포(MVD)가 없다는 것은 아닙니다.

NetOps를 위한 MVD 정의 

오늘날의 생산 파이프라인은 스위치, 라우터, DNS, 멀티 클라우드 라우팅(GSLB)과 같은 공유 리소스와 로드 밸런서, WAF, 애플리케이션 액세스 제어와 같은 앱별 애플리케이션 서비스로 구성됩니다.

흥미로운 점은 공유 자원과 관련된 변화율을 살펴보면 그 속도가 매우 미미하다는 것입니다. 즉, 변화율이 낮습니다. 그게 좋은데, 그들은 방해에 대한 허용 범위가 낮거든요. 앱별 리소스로 이동하면 더 높은 변화율과 더 큰 방해 허용 범위를 확인할 수 있습니다.

결국, 앱별 아키텍처의 이점 중 하나는 데이터 경로를 격리하여 문제가 발생해도 다른 앱이 중단되지 않도록 보호하는 것입니다.

우리 조사에 따르면 해당 데이터 경로를 따라 기업들이 애플리케이션을 제공하고 보안을 강화하기 위해 사용하는 평균 16개의 서로 다른 애플리케이션 서비스가 존재합니다. 네트워크 방화벽과 DNS와 같은 일부 리소스는 공유 리소스입니다. 그렇지 않은 경우도 있고, 적어도 그럴 필요가 없는 경우도 있습니다. 현재는 공유 플랫폼에 배포될 수 있지만, 적절한 이유가 있다면 자체 데이터 경로에 맞춰 설계될 수도 있습니다.

물론, 제가 말씀드릴 것은 바로 그것입니다.

좋은 이유는 원래 앱에 밀접하게 결합된 애플리케이션 서비스에 대해 앱별 아키텍처를 채택 하면 애플리케이션에 대한 MVD를 효과적으로 개발할 수 있다는 것입니다.

MVP에 대한 정의에서 알 수 있듯이 "제품"(우리의 경우 앱 배포)은 완전히 자동화될 필요가 없습니다. 가장 위험하고 허용 범위가 가장 좁은 리소스를 계속해서 수동으로 구성(및 검증)해야 한다는 전제 하에 운영한다면 여전히 우위를 점할 수 있습니다. 방화벽과 DNS와 같은 핵심 서비스는 변경률이 매우 낮으므로 수동 방식이 배포 일정에 큰 영향을 미치지 않는다고 가정할 수 있습니다. 앱별 애플리케이션 서비스의 대부분을 자동화하면 더욱 그렇습니다. 그러면 운영자와 엔지니어가 필요할 경우 수동으로 변경할 수 있는 시간이 확보되기 때문입니다.

핵심(공유) 서비스와 앱당 애플리케이션 서비스의 비율이 약 1:3*이라고 가정하면 평균적인 조직에서는 수동으로 관리해야 할 공유 리소스가 최소 4개이고 자동화해야 할 앱당 리소스가 12개라는 뜻입니다.

광범위한 애플리케이션 서비스 목록을 살펴보면( 현재 30개의 고유한 서비스를 추적 중입니다 ) 일부 서비스는 앱을 제공하거나 보호하는 데 필수적 (DDoS, WAF, 확장을 위한 부하 분산, 앱 액세스)이고, 다른 서비스는 말하자면 향상된 기능입니다 . 성능 개선 가속 옵션이나 생산성 향상을 위한 SSO(Single Sign On)와 같은 애플리케이션 서비스가 해당됩니다.

따라서 MVD 구현을 고려한다면 Agile 방식을 취하고 1일차 제공 및 보안에 중요한 애플리케이션 서비스에 집중할 수 있습니다. 이는 우리가 개선 사항을 무시한다는 것을 의미하지 않습니다. 단지 처음에는 중요한 기능에 집중하고 이를 먼저 자동화한다는 것을 의미합니다. 생산성이나 성과를 향상시키는 서비스는 여전히 수동으로 관리할 수 있지만, MVD의 경우 수익에 영향을 미치는 서비스에 집중하고자 합니다.

Agile Network에 대한 MVD 접근 방식

MVD를 정의하고 제공하려는 의도로 자동화에 접근한다는 것은 우리가 더 빠르게 움직이고 있다는 것을 의미합니다(우리는 더 민첩합니다). 또한 우리는 각 스프린트(분기가 아닌 주 단위로 측정)마다 자동화를 반복하여 개선하고 확장할 수 있는 기회를 얻습니다. 그러면 견고하고 지속 가능한 제품(자동화된 배포)을 얻을 수 있습니다.

자동화에 대한 MVD 기반 전략을 채택하려면 아키텍처뿐만 아니라 애플리케이션에 초점을 맞춘 접근 방식과 태도에 대한 헌신이 필요합니다. 이러한 접근 방식에는 운영 관점과 비즈니스 관점 모두에서 애플리케이션과 그 요구 사항을 이해하는 것이 필요하기 때문입니다. 한 앱의 MVD는 다른 앱의 MVD와 일치하지 않을 수 있습니다. 이는 고정된 수동 네트워크에서 민첩한(자동화된) 파이프라인으로 전환할 때 앱별 아키텍처가 매우 중요한 구성 요소인 이유 중 하나입니다.

그래서 NetOps에는 최소한의 실행 가능한 배포가 있는 것으로 밝혀졌습니다. 즉, 네트워크 자동화에 Agile 접근 방식을 취할 수 있다는 의미입니다. Agile 네트워크 이니셔티브의 일부로 앱별 아키텍처로 전환하면 무한히 더 빠르고 안전할 것입니다.

(거의) 모든 네트워크 작업을 자동화합니다.  

*그건 목록과 내 경험, 그리고 내 (강력한) 의견을 바탕으로 한 완전히 SWAG예요. 귀하의 마일리지와 정의는 다를 수 있습니다.