앱의 중력적 인력이 네트워크를 포킹하고 있습니다.

네트워크가 포킹되고 있습니다. 분기화. 분산. 데이터 센터 네트워크의 애플리케이션 측면에서 기업 네트워크라는 조용한 교외 지역에서 복잡하고 시끄러운 도시 지역으로 네트워크 서비스가 이전되는 현상을 설명하는 데 원하는 용어를 사용하세요. 오늘 논의의 요점은 용어가 아닙니다. 오히려 오늘은 이런 일이 왜 일어나는지에 대해 곰곰이 생각해 보겠습니다.

어떤 사람들은 "로리, 기업 네트워크가 하드웨어에 크게 기반을 두고 있고 하드웨어는 개발 및 운영에서 진행되는 더욱 세련되고 민첩한 환경에 적응하는 데 필요한 유연성과 민첩성이 부족하다는 것은 분명합니다."라고 말할 수도 있습니다.

글쎄요, 아닙니다. 하드웨어나 소프트웨어에 대한 것이 아닙니다. 실제로 무엇을 하든 하드웨어가 있어야 하기 때문입니다(RAM, 컴퓨팅, 네트워크 액세스와 같은 리소스는 허공에서 실현되지 않습니다). 이는 두 네트워크 각각을 지배하는 운영 문화와 현실에 대한 것이며, 두 네트워크는 한 쪽에서 다른 쪽으로 일부 서비스를 제공합니다.

사실, 저는 진짜 일어나고 있는 일은 이제 애플리케이션이 중심이 되어서 애플리케이션과 관련된 모든 서비스를 애플리케이션으로 끌어들이고 있다는 것이라고 말하고 싶습니다. 이는 마치 달이 지구로 끌리는 것과 비슷합니다.

문제는 부하 분산, 캐싱, 가속, 웹 앱 보안과 같은 애플리케이션 관련 서비스가 모두 특정 애플리케이션에 매우 고유하다는 것입니다. 이러한 서비스는 "모두에게 맞는 단일 서비스"가 아닙니다. 반면, 이러한 서비스는 하나의 애플리케이션을 제공하고 보호하고 최적화하기 위한 정책을 갖춘, 애플리케이션 중심의 고도로 집중된 서비스입니다.

전부는 아닙니다. 모두 같은 종류는 아닙니다. 딱 하나뿐이에요. 저쪽이에요.

이는 네트워크 방화벽이나 IPS/IDS와는 매우 다릅니다. 이러한 방화벽이나 IPS/IDS의 작동은 애플리케이션에 그다지 특화되어 있지 않습니다. 웹 앱은 80번 포트를 통해 실행되므로, 이 포트를 열어 방화벽을 통한 액세스를 허용하세요. 거기에는 "애플리케이션" 특이성이 거의 없습니다. 다만, 같은 프로토콜(HTTP)을 사용하고 같은 포트에서 실행된다는 점만 빼고요.

반대로, 어떤 종류의 데이터(문자열? 정수? 영숫자?)를 사용할 것인지, 그리고 얼마나 많은 데이터(15자?)를 사용할 것인지를 지정하는 보안 정책을 설정하는 것은 12? 100?)이 단일 URI(/login.x)와 연결된 단일 입력 필드(사용자 이름? 이메일? 댓글?)와 연결될 수 있다는 것은 꽤나 괴상한 애플리케이션 특정입니다. 로드 밸런싱 서비스에서 애플리케이션과 관련된 최소화, 스타일 시트 연결, 상태 모니터링을 관리하는 정책도 마찬가지입니다.

친화성이 중요한 이유

현재 평균적인 기업은 약 508개의 애플리케이션을 관리하고 있다고 합니다. 우리 조사에 따르면, 실제로 조직의 31%가 500개 이상을 보유하고 있지만, 그게 중요한 것은 아닙니다. 그저 기준일 뿐입니다. 이는 많은 조직이 훨씬 더 많은 애플리케이션을 구축할 계획을 세우고 있기 때문에 기준이 됩니다. 그리고 반드시 애플리케이션의 수는 변경하지 않지만, 앞서 언급한 애플리케이션 관련 서비스가 필요한 "시스템"의 수는 변경하는 마이크로서비스 아키텍처를 채택하는 조직도 있습니다.

그래서. 어떤 조직이 관리하는 애플리케이션의 수를 두 배로 늘리려고 한다고 상상해보세요. 예를 들어 500개로 시작했는데 갑자기 1000개가 되었다고 가정해 보겠습니다. 그들은 각각의 정책을 프로비저닝, 구성 및 관리해야 합니다. 각 앱에 확장성 1개, 보안성 1개 등 2개만 필요하다고 가정하면 계산이 훨씬 수월해질 겁니다. 처리해야 할 정책이 2000개나 됩니다. 준비가 된? 가다.

응. 문제는 기업 네트워크의 "하드웨어"가 그것을 처리할 수 없다는 것이 아닙니다. 오히려 특수 목적의 하드웨어 이기 때문에 일반 용도의 서버를 훨씬 뛰어넘는 용량을 갖추고 있기 때문에 가능합니다. 문제는 이 모든 일을 하는 데 필요한 프로세스와 인력이다. 필요한 장치의 수만이 문제가 아니라 배포해야 하는 고유한(애플리케이션과 관련된) 정책의 수도 문제입니다.

배포뿐만 아니라 업데이트도 이뤄졌습니다. 애플리케이션 관련 정책은 특정 애플리케이션에 맞게 구성되므로 앱이 업그레이드되거나 수정 사항이 도입되면 관련 앱 서비스 정책도 업데이트해야 할 가능성이 높습니다. 그리고 조직에서 더 빈번하게 배포를 원하면, 글쎄요.. 회사 네트워크 담당자들이 완전히 압도당할 것이라고 상상할 수 있을 겁니다.

울타리 반대편, 앱 네트워크에서는 개발자와 운영자들이 갈구하고 있습니다. 앱을 전달하고 배포하고 싶어합니다. 그들은 자동화 및 오케스트레이션 분야의 새로운 기술을 사용하여 해당 프로세스를 가속화할 준비가 되었습니다.

이에 따라 그들은 점점 더 많은 애플리케이션 관련 서비스에 대한 책임을 맡고 이를 배포 아키텍처와 프로세스에 통합하고 있습니다. DevOps에 대한 인지도가 높아지고 SDN에서 업계의 격려가 커지면서 네트워크 서비스는 거의 모두 API를 통해 구축되고 있습니다. 다른 많은 솔루션은 애플리케이션을 지원하는 데 필요한 인프라를 관리하고 배포하기 위해 "코드로서의 인프라" 접근 방식을 사용하는 운영자의 손에 딱 맞는 템플릿을 제공합니다.

이것이 애플리케이션 네트워크에 점점 더 많은 "애플리케이션 서비스"가 등장하고 기업 IT의 중심이 애플리케이션으로 옮겨가는 이유입니다.

이는 비즈니스 및 운영 확장 전략입니다. 이는 더 많은 네트워크 또는 애플리케이션 인력을 문제에 투입하여 브룩스의 법칙 에 위배되지 않으면서도 애플리케이션 포트폴리오의 급격한 성장에 대처하는 방법입니다.  이는 네트워크 운영자가 현재보다 2~3배, 혹은 그 이상의 정책을 관리해야 하는 상황에서 발생하는 중단 없이 IT 부서가 앱을 더 빠르고 더 자주 시장에 출시할 수 있는 방법입니다.