클라우드와 마찬가지로 SDN도 정의 피로에 시달림
클라우드의 초기 역사, 그리 오래 전이 아니지만, 주요 모델(잊으셨다면 IaaS, PaaS, SaaS) 간에 구별 없이 "클라우드"의 타의 추종을 불허하는 시장 침투를 선전하는 성장 및 도입 보고서를 흔히 볼 수 있었습니다. 이로 인해 세 가지 모델 모두 엄청난 성장을 경험하고 있는 것처럼 보였고, 일부가 예측했듯이 클라우드가 우리가 아는 데이터 센터를 근절시킬 것처럼 보였습니다.
몇 년이 빠르게 흘러 지금은 더 나은 시장 분석을 통해 클라우드의 엄청난 성장이 주로 SaaS 쪽에서 이루어졌다는 것을 알 수 있습니다. LOB(사업부) 이해 관계자가 IT가 우리를 위해 패키지 소프트웨어를 구현하는 모델에서 SaaS가 지금 당장 우리가 원하는 것을 제공하는 모델로 전환하는 데 이점이 있음을 알게 되었기 때문입니다. 의심할 여지 없이, "클라우드"에서 가장 큰 성장은 지금까지 온프레미스에서 "클라우드" 애플리케이션으로 비즈니스 운영을 이전한 것입니다.
" 2018년까지 전체 클라우드 작업 부하의 59%가 SaaS(Software-as-a-Service) 작업 부하가 될 것"으로 예상하는데, 이는 2013년 41%보다 증가한 수치입니다. Cisco는 2018년까지 전체 클라우드 작업 부하의 28%가 IaaS(Infrastructure-as-a-Service) 작업 부하가 될 것으로 예측하는데, 이는 2013년 44%에서 감소한 수치입니다. 또한, 2018년에는 전체 클라우드 작업 부하의 13%가 PaaS(Platform-as-a-Service) 작업 부하가 될 것으로 예상되는데, 이는 2013년 15%에서 감소한 수치입니다. 다음 그래픽은 2013년부터 2018년까지의 IaaS, PaaS 및 SaaS 예측에 대한 비교 분석을 제공합니다. "( http://softwarestrategiesblog.com/tag/idc-saas-forecasts/ )
따라서 일반적으로 조직에 "클라우드"를 도입하는지 묻는다면 '예'라는 대답을 받을 가능성이 높습니다. 이는 그들이 어떤 종류의 클라우드를 채택하고 있는지에 대해 아무것도 말해주지 않으며, 따라서 채택에 따라 어떤 종류의 과제에 직면하게 될지 예측하거나 논평하는 것이 거의 불가능합니다. 결국 각 클라우드 모델은 고유한 과제를 안고 있습니다. 일부는 공유되지만(ID 관리가 세 가지 모델 모두에서 문제가 될 수 있음) 일부는 그렇지 않습니다. 웹 애플리케이션 보안은 대부분 SaaS가 아닌 IaaS에 배포된 앱의 과제입니다.
그래서 기본적으로 "클라우드"라는 용어는 어떤 종류의 한정사 없이는 의미가 없습니다.
이는 오늘날 SDN에도 해당합니다. 다양한 모델이 적용되고 있으며, 각 모델마다 고유한 아키텍처 요구 사항이 있으며, 이로 인해 과제도 발생합니다.
SDN 정의에 오버레이 프로토콜(VXLAN 및 NVGRE)을 포함하는 것에 대한 동료 Nathan Pearce의 이 비난을 고려해 보십시오. 어떤 SDN 프로토콜이 당신에게 적합할까요 ? 네이선은 SDN 정의에 오버레이 프로토콜을 포함시키려면 다른 캡슐화 프로토콜도 SDN으로 명명해야 한다고 옳게 제안했습니다.
문제는 클라우드와 마찬가지로 SDN도 여러 모델을 광범위하게 포함한다는 점입니다. OpenFlow를 기반으로 하고 상태 비저장 네트워크(2~4계층)만 포함하는 기존(또는 선호하는 경우 클래식) 정의가 있습니다. 네트워크를 운영화하는 데 초점을 맞춘 아키텍처 모델이 있습니다. SDN의 프로그래밍 측면을 프로비저닝 및 관리 자동화의 관점에서 접근합니다. 이는 종종 광범위하게 "네트워크 관리 및 오케스트레이션"(MANO)이라고 합니다.
그런 다음 전체 스택에 자동화된 네트워크를 구축하기 위해 프로그래밍 가능성에 의존하는 혼합 모델이 있습니다. 이 모델은 7개 OSI 계층을 모두 포함하지만 네트워크가 실시간 트래픽에 따라 라우팅과 정책 시행을 조정할 수 있는 기능에 중점을 둡니다. 이를 "자동화된 네트워크"라고 부르는 것이 더 적절합니다.
이 세 가지 모델은 각각 고유한 과제(그리고 이점)를 가지고 있습니다. 그리고 조직이 목표를 달성하기 위해 이러한 모델을 결합하는 것을 막을 수 있는 것은 없습니다(조직의 82%가 멀티 클라우드 전략을 계획하는 방식과 매우 유사합니다(RightScale, State of the Cloud 2015)). 하지만 누군가에게 SDN을 채택하거나 구현하고 있는지 물었을 때 그들이 "예"라고 대답한다면, 그들이 실제로 무엇을 하고 있는지 전혀 알 수 없다는 사실이 여전히 남아 있습니다. OpenFlow인가요? 오픈스택? 오픈데이라이트? 네트워크를 자동화하기 위한 스크립트를 작성해 볼까요?
SDN 도입에 대한 현재 통계는 그다지 고무적이지 않으며, 확실히 클라우드가 시장 성숙도에서 보였던 수준에는 전혀 미치지 못합니다.
하지만 정의의 차이를 고려하면 실제로 일어나고 있는 일은 채택이나 관심의 부족이 아니라 공통된 정의의 부족일 가능성이 매우 높습니다.
조직이 SDN(또는 정의 피로로 어려움을 겪는 DevOps)을 수행한다고 말하지 않을 수도 있지만 실제로 수행 중일 가능성이 높다는 것을 보여주는 몇 가지 데이터를 제시하겠습니다.
가장 최근의 애플리케이션 제공 상태 보고서(2016년, 2016년에 출시 예정)를 위해 수집한 결과에서 실제로 "SDN을 실행 중"이라는 응답의 수는 SDN이 "해야 할 일"로 여겨진 지 몇 년이 되었는지에 비추어 볼 때 매우 암울했습니다. 하지만 자동화와 스크립팅 사용에 대한 응답을 살펴보면, 완전히 다른 이야기가 나옵니다. 응답자의 67%는 적어도 하나 이상의 자동화 도구나 프레임워크를 사용하고 있으며, 절반 이상은 2개 이상을 사용하고 있습니다.
그리고 "도구"나 "프레임워크"에는 Python, Juju, Chef, Puppet, OpenStack, VMware, Cisco가 포함됩니다.
이러한 프레임워크와 도구를 사용한다는 것은 자동화와 오케스트레이션에 초점을 맞춘 나머지 두 가지 SDN 정의에 대한 관심이 더 크다는 것을 나타내며, 이는 기존 OpenFlow 기반 정의보다 더 큰 관심을 나타냅니다.
하지만 우리(설문 조사를 작성한 사람들)는 각각의 SDN 모델에 대해 묻지 않았습니다. 우리는 일반적으로 "SDN"에 대해 물었습니다. 이는 정의를 해석에 따라 열어두는 것과 마찬가지로 "클라우드"라는 광범위한 포괄적 용어가 초기 채택 설문 조사 결과를 해석에 열어두는 것입니다.
우리는 SDN이라는 용어를 사용하는 방법과 그 의미에 대해 더 신중하게 생각해야 합니다. 오버레이 프로토콜이 포함되어 있나요? 오버레이 프로토콜이 포함되지 않나요? 우리가 이야기하는 것은 네트워크 자동화인가, 아니면 네트워크 자동화인가? 아니면 우리는 기존의 OpenFlow 기반 네트워킹 모델에 초점을 맞추고 있나요?
그 질문에 대한 답변은 궁극적으로 모든 사람에게 SDN이 오늘날 어떻게 받아들여지고 있는지(또는 받아들여지지 않고 있는지)에 대한 더 나은 이해를 제공하고 누군가가 오버레이 프로토콜을 "SDN"으로 포함해야 한다고 제안했을 때 불쌍한 동료들의 머리가 터지는 것을 막을 것입니다.