NGINX의 제품 부사장으로서 저는 고객 및 사용자와 자주 이야기를 나눕니다. 플랫폼 운영팀, Kubernetes 아키텍트, 애플리케이션 개발자, CISO, CIO, CTO 등 여러분과 같은 분들과 이야기를 나눴습니다. 대화에서 여러분은 제품, 가격 및 라이선스 모델을 포함하여 NGINX에 대한 솔직한 생각을 말씀해 주셨고, 우리의 강점과 약점을 모두 강조해 주셨습니다.
저희가 배운 핵심은 "NGINX가 우주의 중심"이라는 접근 방식이 사용자에게 적합하지 않다는 것입니다. 우리는 애플리케이션 배포와 관련된 모든 것을 위한 통합 관리 영역인 '플랫폼'을 목표로 제품을 개발해 왔습니다. 이러한 목표에 맞춰 개발된 이전 제품 중 일부가 가볍게 사용되고 채택되었다는 것을 알고 있었습니다. NGINX는 자체 개발했든 그렇지 않든 기존 플랫폼의 미션 크리티컬한 구성 요소라고 말씀하셨지만 NGINX는 플랫폼이 아니었습니다. 따라서 저희는 투명한 가격 및 소비 모델을 통해 제품을 더 쉽게 배포, 관리, 보호할 수 있도록 나머지 구성 요소와 더 잘 통합해야 했습니다(이는 매우 중요합니다). 그리고 이 모든 것을 API를 통해 가능하게 해야 했습니다.
기본 메시지는 간단합니다. 사용자가 워크플로, 기존 툴체인 및 프로세스에 NGINX를 의견에 구애받지 않고 쉽게 통합할 수 있도록 하자는 것입니다. 여러분의 의견을 들었습니다. 2024년에는 데이터 플레인과 보안을 위한 사용 사례 구성 및 관리에 대해 훨씬 더 유연하고 단순하며 반복 가능하고 확장 가능한 접근 방식을 취할 것입니다.
여러분의 바람은 충분히 이해가 됩니다. 세상은 변해왔고 앞으로도 계속 변할 것입니다! 클라우드에서 하이브리드로, 멀티클라우드 및 멀티클라우드-하이브리드 설정으로 전환하는 등 다양한 단계를 거쳤습니다. 또한 가상 머신에서 Kubernetes로, API에서 마이크로서비스 및 서버리스로의 변화도 있었습니다. 많은 사람들이 왼쪽으로 이동했고 이로 인해 복잡성이 증가했습니다. 더 많은 팀이 더 많은 관리, 가시성, 강력한 보안을 필요로 하는 더 많은 도구를 사용하며, 이 모든 것이 몇 시간, 며칠, 몇 주가 아니라 몇 분 안에 확장할 수 있어야 하는 앱을 뒷받침합니다. 그리고 최신 촉진제인 인공지능(AI)은 레거시 애플리케이션 및 인프라 아키텍처에 상당한 압박을 가하고 있습니다.
향후 NGINX 제품 릴리스에서 다룰 예정 사항
NGINX 제품의 뼈대는 항상 견고하고 실전에서 테스트를 거쳤으며 성능이 뛰어나지만, 사용자가 NGINX의 모든 측면을 소비, 관리, 관찰하는 방식은 시대를 따라잡지 못했습니다. 새로운 제품 출시와 다양한 새로운 기능으로 이를 개선하기 위해 빠르게 움직이고 있습니다. 이에 대한 자세한 내용은 2월 6일부터 8일까지 열리는 F5의 컨퍼런스 AppWorld 2024에서 발표할 예정입니다. 향후 제품 릴리스에서 해결하고자 하는 구체적인 문제점은 다음과 같습니다.
문제점 #1: 배포 환경의 다양성으로 인해 관리가 어려운 최신 애플리케이션
오늘날 CIO와 CTO는 다양한 애플리케이션 배포 방식 중에서 선택할 수 있습니다. 이는 성능, 기능, 복원력 측면에서 훨씬 더 많은 선택이 가능하다는 점에서 축복입니다. 하지만 다양성은 복잡성과 확장성으로 이어지기 때문에 저주이기도 합니다. 예를 들어, AWS에서 실행 중인 애플리케이션을 관리하려면 Azure Cloud에서 애플리케이션을 관리하는 것과는 다른 구성, 도구 및 부족별 지식이 필요합니다.
컨테이너는 대규모 애플리케이션 배포를 표준화했지만, 컨테이너 아래의 모든 것(또는 컨테이너 안팎으로 이동하는 모든 것)은 여전히 차별화되어 있습니다. 사실상의 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 이러한 프로세스를 정리해야 했습니다. 하지만 Amazon EKS, Azure Kubernetes Service(AKS), Google Kubernetes Engine(GKE)에 배포해 본 사람이라면 누구나 알 수 있듯이 전혀 비슷하지 않다는 것을 알 수 있습니다.
이렇게 다양한 환경에서 NGINX 제품을 관리하려면 상당한 운영 리소스가 필요하고 낭비가 발생한다고 말씀해 주셨습니다. 또한 서버리스 환경에서 앱을 시작하고, Kubernetes 환경에서 확장하고, 개발 목적으로 클라우드에서 실행되는 소규모 내부 배포를 유지하는 등 동적인 환경에서는 연간 라이선스를 기반으로 하는 가격 모델이 무너지게 됩니다.
문제점 #2: 다양한 환경에서 실행되고 라이선스 유형에 걸쳐 있는 앱은 보안이 어렵습니다.
다양한 환경의 복잡성으로 인해 최신 앱이 배포된 위치를 파악하고 모니터링한 다음 적절한 보안 조치를 적용하기가 어려울 수 있습니다. 글로벌 로드 밸런서로 NGINX Plus를 배포하고 다양한 마이크로 서비스를 위해 NGINX Open Source를 배포하여 각각 다른 클라우드에서 또는 다른 유형의 애플리케이션 위에서 실행하고 있을 수도 있습니다. 또한 개인 정보 보호, 데이터 보호, 트래픽 관리를 위해 서로 다른 것을 요구할 수 있습니다.
각 퍼머테이션은 새로운 보안 문제를 추가합니다. 표준적이고 포괄적인 솔루션이 없기 때문에 운영상의 복잡성과 구성 오류의 가능성이 있습니다. 물론, 어떤 유형의 보안을 어떤 NGINX 솔루션에 적용할 수 있는지 혼란스럽게 만들어 이러한 복잡성을 가중시킨 것도 인정합니다.
이해합니다. 고객은 NGINX를 활용하는 모든 애플리케이션을 보호할 수 있는 단일 방법이 필요합니다. 이 통합 보안 솔루션은 대부분의 사용 사례를 포괄하고 모든 클라우드, 온프레미스, 서버리스 및 기타 환경에 동일한 도구, 대시보드 및 운영 프로세스를 배포해야 합니다. 또한 NGINX 커뮤니티의 집단 지성과 전 세계 트래픽에 대한 전례 없는 관점을 활용하여 보다 지능적인 보안 접근 방식으로 나아가는 것이 중요하다는 것을 잘 알고 있습니다.
문제점 #3: 최신 앱의 비용 관리는 복잡하고 낭비를 초래합니다.
변화하는 세상에서 모든 조직은 티켓을 제출하거나 Slack을 보내지 않고도 개발자와 실무자가 업무를 더 잘 수행할 수 있도록 지원하기를 원합니다. 하지만 현실은 달랐습니다. 온프레미스, 클라우드, 멀티클라우드 환경에 걸쳐 분산 애플리케이션과 애플리케이션을 관리하기 위한 Kubernetes, 서버리스, 기타 메커니즘을 통해 복잡성을 어느 정도 추상화할 수 있었습니다. 하지만 이러한 발전은 대부분 컨테이너와 애플리케이션 내부에 국한되어 있었습니다. 네트워킹, 보안, 통합 가시성과 같은 애플리케이션 주변 계층이나 CI/CD에는 잘 적용되지 않았습니다.
이전 고충에서 이러한 문제를 암시했지만, 결론은 복잡성은 시간과 노력, 보안 및 복원력 저하라는 측면에서 큰 비용을 초래한다는 것입니다. 점점 더 복잡해지는 시스템을 유지 관리하는 것은 근본적으로 어렵고 리소스 집약적입니다. 가격 및 라이선스 복잡성은 또 다른 불만 요소를 추가합니다. NGINX는 사용자가 실수로 과소비를 했을 때 사용자에게 비용을 청구하는 '정가제' 회사가 아닙니다.
하지만 SaaS, API, 마이크로서비스의 세계에서는 연 단위나 시트 또는 사이트 라이선스 단위가 아닌 사용한 만큼만 지불하는 것을 원합니다. 전체 기술 인프라 및 애플리케이션 포트폴리오에 걸쳐 모든 NGINX 제품 및 서비스에 대해 소비량에 따라 이해하기 쉬운 가격 모델을 원합니다. 또한 팀에서 실행하는 모든 오픈 소스 모듈에 대한 지원 및 보안을 통합하여 원하는 부분만 비용을 지불할 수 있는 방법을 원합니다.
이를 위해서는 NGINX의 제품 패키징 및 가격 책정 방식에 약간의 변화가 필요합니다. 궁극적인 해결책은 다른 SaaS와 마찬가지로 단순성, 투명성, 사용한 만큼만 지불하는 방식이어야 합니다. 충분히 이해합니다. 그리고 위의 세 가지 문제점을 모두 해결할 수 있는 훌륭한 기능이 준비되어 있습니다.
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
NGINX의 제품 부사장으로서 저는 고객 및 사용자와 자주 이야기를 나눕니다. 플랫폼 운영팀, Kubernetes 아키텍트, 애플리케이션 개발자, CISO, CIO, CTO 등 여러분과 같은 분들과 이야기를 나눴습니다. 대화에서 여러분은 제품, 가격 및 라이선스 모델을 포함하여 NGINX에 대한 솔직한 생각을 말씀해 주셨고, 우리의 강점과 약점을 모두 강조해 주셨습니다.
저희가 배운 핵심은 "NGINX가 우주의 중심"이라는 접근 방식이 사용자에게 적합하지 않다는 것입니다. 우리는 애플리케이션 배포와 관련된 모든 것을 위한 통합 관리 영역인 '플랫폼'을 목표로 제품을 개발해 왔습니다. 이러한 목표에 맞춰 개발된 이전 제품 중 일부가 가볍게 사용되고 채택되었다는 것을 알고 있었습니다. NGINX는 자체 개발했든 그렇지 않든 기존 플랫폼의 미션 크리티컬한 구성 요소라고 말씀하셨지만 NGINX는 플랫폼이 아니었습니다. 따라서 저희는 투명한 가격 및 소비 모델을 통해 제품을 더 쉽게 배포, 관리, 보호할 수 있도록 나머지 구성 요소와 더 잘 통합해야 했습니다(이는 매우 중요합니다). 그리고 이 모든 것을 API를 통해 가능하게 해야 했습니다.
기본 메시지는 간단합니다. 사용자가 워크플로, 기존 툴체인 및 프로세스에 NGINX를 의견에 구애받지 않고 쉽게 통합할 수 있도록 하자는 것입니다. 여러분의 의견을 들었습니다. 2024년에는 데이터 플레인과 보안을 위한 사용 사례 구성 및 관리에 대해 훨씬 더 유연하고 단순하며 반복 가능하고 확장 가능한 접근 방식을 취할 것입니다.
여러분의 바람은 충분히 이해가 됩니다. 세상은 변해왔고 앞으로도 계속 변할 것입니다! 클라우드에서 하이브리드로, 멀티클라우드 및 멀티클라우드-하이브리드 설정으로 전환하는 등 다양한 단계를 거쳤습니다. 또한 가상 머신에서 Kubernetes로, API에서 마이크로서비스 및 서버리스로의 변화도 있었습니다. 많은 사람들이 왼쪽으로 이동했고 이로 인해 복잡성이 증가했습니다. 더 많은 팀이 더 많은 관리, 가시성, 강력한 보안을 필요로 하는 더 많은 도구를 사용하며, 이 모든 것이 몇 시간, 며칠, 몇 주가 아니라 몇 분 안에 확장할 수 있어야 하는 앱을 뒷받침합니다. 그리고 최신 촉진제인 인공지능(AI)은 레거시 애플리케이션 및 인프라 아키텍처에 상당한 압박을 가하고 있습니다.
향후 NGINX 제품 릴리스에서 다룰 예정 사항
NGINX 제품의 뼈대는 항상 견고하고 실전에서 테스트를 거쳤으며 성능이 뛰어나지만, 사용자가 NGINX의 모든 측면을 소비, 관리, 관찰하는 방식은 시대를 따라잡지 못했습니다. 새로운 제품 출시와 다양한 새로운 기능으로 이를 개선하기 위해 빠르게 움직이고 있습니다. 이에 대한 자세한 내용은 2월 6일부터 8일까지 열리는 F5의 컨퍼런스 AppWorld 2024에서 발표할 예정입니다. 향후 제품 릴리스에서 해결하고자 하는 구체적인 문제점은 다음과 같습니다.
문제점 #1: 배포 환경의 다양성으로 인해 관리가 어려운 최신 애플리케이션
오늘날 CIO와 CTO는 다양한 애플리케이션 배포 방식 중에서 선택할 수 있습니다. 이는 성능, 기능, 복원력 측면에서 훨씬 더 많은 선택이 가능하다는 점에서 축복입니다. 하지만 다양성은 복잡성과 확장성으로 이어지기 때문에 저주이기도 합니다. 예를 들어, AWS에서 실행 중인 애플리케이션을 관리하려면 Azure Cloud에서 애플리케이션을 관리하는 것과는 다른 구성, 도구 및 부족별 지식이 필요합니다.
컨테이너는 대규모 애플리케이션 배포를 표준화했지만, 컨테이너 아래의 모든 것(또는 컨테이너 안팎으로 이동하는 모든 것)은 여전히 차별화되어 있습니다. 사실상의 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 이러한 프로세스를 정리해야 했습니다. 하지만 Amazon EKS, Azure Kubernetes Service(AKS), Google Kubernetes Engine(GKE)에 배포해 본 사람이라면 누구나 알 수 있듯이 전혀 비슷하지 않다는 것을 알 수 있습니다.
이렇게 다양한 환경에서 NGINX 제품을 관리하려면 상당한 운영 리소스가 필요하고 낭비가 발생한다고 말씀해 주셨습니다. 또한 서버리스 환경에서 앱을 시작하고, Kubernetes 환경에서 확장하고, 개발 목적으로 클라우드에서 실행되는 소규모 내부 배포를 유지하는 등 동적인 환경에서는 연간 라이선스를 기반으로 하는 가격 모델이 무너지게 됩니다.
문제점 #2: 다양한 환경에서 실행되고 라이선스 유형에 걸쳐 있는 앱은 보안이 어렵습니다.
다양한 환경의 복잡성으로 인해 최신 앱이 배포된 위치를 파악하고 모니터링한 다음 적절한 보안 조치를 적용하기가 어려울 수 있습니다. 글로벌 로드 밸런서로 NGINX Plus를 배포하고 다양한 마이크로 서비스를 위해 NGINX Open Source를 배포하여 각각 다른 클라우드에서 또는 다른 유형의 애플리케이션 위에서 실행하고 있을 수도 있습니다. 또한 개인 정보 보호, 데이터 보호, 트래픽 관리를 위해 서로 다른 것을 요구할 수 있습니다.
각 퍼머테이션은 새로운 보안 문제를 추가합니다. 표준적이고 포괄적인 솔루션이 없기 때문에 운영상의 복잡성과 구성 오류의 가능성이 있습니다. 물론, 어떤 유형의 보안을 어떤 NGINX 솔루션에 적용할 수 있는지 혼란스럽게 만들어 이러한 복잡성을 가중시킨 것도 인정합니다.
이해합니다. 고객은 NGINX를 활용하는 모든 애플리케이션을 보호할 수 있는 단일 방법이 필요합니다. 이 통합 보안 솔루션은 대부분의 사용 사례를 포괄하고 모든 클라우드, 온프레미스, 서버리스 및 기타 환경에 동일한 도구, 대시보드 및 운영 프로세스를 배포해야 합니다. 또한 NGINX 커뮤니티의 집단 지성과 전 세계 트래픽에 대한 전례 없는 관점을 활용하여 보다 지능적인 보안 접근 방식으로 나아가는 것이 중요하다는 것을 잘 알고 있습니다.
문제점 #3: 최신 앱의 비용 관리는 복잡하고 낭비를 초래합니다.
변화하는 세상에서 모든 조직은 티켓을 제출하거나 Slack을 보내지 않고도 개발자와 실무자가 업무를 더 잘 수행할 수 있도록 지원하기를 원합니다. 하지만 현실은 달랐습니다. 온프레미스, 클라우드, 멀티클라우드 환경에 걸쳐 분산 애플리케이션과 애플리케이션을 관리하기 위한 Kubernetes, 서버리스, 기타 메커니즘을 통해 복잡성을 어느 정도 추상화할 수 있었습니다. 하지만 이러한 발전은 대부분 컨테이너와 애플리케이션 내부에 국한되어 있었습니다. 네트워킹, 보안, 통합 가시성과 같은 애플리케이션 주변 계층이나 CI/CD에는 잘 적용되지 않았습니다.
이전 고충에서 이러한 문제를 암시했지만, 결론은 복잡성은 시간과 노력, 보안 및 복원력 저하라는 측면에서 큰 비용을 초래한다는 것입니다. 점점 더 복잡해지는 시스템을 유지 관리하는 것은 근본적으로 어렵고 리소스 집약적입니다. 가격 및 라이선스 복잡성은 또 다른 불만 요소를 추가합니다. NGINX는 사용자가 실수로 과소비를 했을 때 사용자에게 비용을 청구하는 '정가제' 회사가 아닙니다.
하지만 SaaS, API, 마이크로서비스의 세계에서는 연 단위나 시트 또는 사이트 라이선스 단위가 아닌 사용한 만큼만 지불하는 것을 원합니다. 전체 기술 인프라 및 애플리케이션 포트폴리오에 걸쳐 모든 NGINX 제품 및 서비스에 대해 소비량에 따라 이해하기 쉬운 가격 모델을 원합니다. 또한 팀에서 실행하는 모든 오픈 소스 모듈에 대한 지원 및 보안을 통합하여 원하는 부분만 비용을 지불할 수 있는 방법을 원합니다.
이를 위해서는 NGINX의 제품 패키징 및 가격 책정 방식에 약간의 변화가 필요합니다. 궁극적인 해결책은 다른 SaaS와 마찬가지로 단순성, 투명성, 사용한 만큼만 지불하는 방식이어야 합니다. 충분히 이해합니다. 그리고 위의 세 가지 문제점을 모두 해결할 수 있는 훌륭한 기능이 준비되어 있습니다.
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기