클라우드와 컨테이너가 애플리케이션 서비스를 분산시키는 방식
- 애플리케이션은 위치에서부터 지원 배송 인프라의 폼 팩터에 이르기까지 모든 것에 대한 결정을 주도합니다. 조직의 55%가 애플리케이션 요구 사항과 필요 사항에 따라 클라우드를 선택합니다. 40%는 앱에 맞는 폼 팩터를 선택할 수 있기를 원합니다. (2018년 애플리케이션 제공 현황)
- 클라우드 및 마이크로서비스 아키텍처가 앱을 분할하고 분산함에 따라 공유 인프라는 이점이 아닌 부담이 되어 자본 및 운영 비용이 증가합니다.
- 비용, 구성 및 업그레이드는 앱별 애플리케이션 서비스를 통해 앱별 아키텍처를 지원하는 데 있어 핵심적인 요소입니다.
- 최신 앱과 아키텍처를 지원하려면 애플리케이션 서비스에 대한 앱별 접근 방식이 필요합니다.
지난 몇 년 동안 우리는 Amazon, Microsoft, Google 등의 클라우드 공급업체가 기업의 애플리케이션 서비스 요구에 부응하기 위해 협력하는 모습을 보았습니다.
오늘날 클라우드 마켓플레이스에서 보안(웹 애플리케이션 방화벽 등)뿐 아니라 성능(캐싱) 및 ID 관리까지 처리하는 다양한 애플리케이션 서비스를 찾을 수 있으며, 그 수는 계속 늘어나고 있습니다. 이는 놀랄 일이 아닙니다. 기업들은 앱을 더 빠르고 안전하게 만들기 위해 평균 16개의 서로 다른 애플리케이션 서비스를 활용합니다 . 그 숫자는 매년 늘어나고 있습니다. 기업들은 클라우드의 속도 때문에 이를 희생하지 않을 것입니다.
그런 측면에서 애플리케이션 서비스는 고객과 클라우드 제공자 모두에게 영향을 미칩니다. 하지만 일방통행은 아닙니다. 클라우드와 점점 더 늘어나는 컨테이너 역시 애플리케이션 서비스와 그 제공 방식에 상당한 영향을 미치고 있습니다.
기업 조직이 프라이빗(온프레미스) 클라우드에 계속 투자하고 컨테이너를 실험함에 따라 기존의 애플리케이션 서비스 제공 모델이 항상 적합하지 않다는 것을 알게 되었습니다.
대부분의 네트워크와 마찬가지로, 애플리케이션 서비스는 오랫동안 확장 가능하고 안정적인 하드웨어로 지원되는 플랫폼(종종 애플리케이션 전송 컨트롤러 또는 ADC라고 함)을 통해 제공되어 왔습니다. 이러한 장치는 높은 가용성과 확장성을 염두에 두고 설계되어 수백 개의 애플리케이션을 동시에 지원할 수 있습니다. 네트워크든 애플리케이션이든 공유 인프라는 오랫동안 비용 측면에서 이점을 제공해 왔습니다. 자본과 운영 비용을 여러 애플리케이션에 분산하는 것이 합리적이었습니다.
앱과 아키텍처가 등장할 때까지는 그렇지 않았습니다.
점점 더 많은 앱과 아키텍처가 애플리케이션과 관련된 접근 방식을 필요로 하고 있습니다. 예를 들어, 현대의 마이크로서비스는 단일 애플리케이션에 대한 애플리케이션 서비스를 배포하기 위한 빠르고 확장 가능하며 저렴한 플랫폼을 요구합니다.
공유 서비스 플랫폼은 의도적으로 설계된 앱별 플랫폼 방식으로는 이런 수요를 충족할 수 없습니다. 그럴 만한 이유가 세 가지 있습니다.
- 비용. 12인승 밴을 사용할 사람이 자신뿐이라면 굳이 사지 않을 겁니다. 추가 공간을 확보하려면 사전 비용과 운영 비용이 추가로 발생합니다. 적절한 상황(및 적절한 애플리케이션)에서 공유 인프라는 애플리케이션당 비용을 낮추고 재정적, 운영적 측면에서 매우 합리적입니다. 하지만 단일 애플리케이션만 지원하려고 하면 가치는 더하지 않고 비용만 늘어날 뿐입니다.
- 구성. 최신 앱과 아키텍처는 빈번한 업데이트를 염두에 두고 개발되고 배포되고 있습니다. 동일한 일정에 속하지 않은 다른 앱 8개와 플랫폼을 공유하는 경우, 무언가 잘못되어 해당 앱에 영향을 미치게 되면 각 앱은 약간 화가 날 수도 있습니다. 구성이 많아질수록(그리고 구성이 커질수록) 구성을 다시 로드하거나 변경할 때마다 해당 구성을 읽고 확인하는 데 걸리는 시간도 더 많아진다는 점은 말할 것도 없습니다.
- 업그레이드. Bob이 공유 플랫폼을 업그레이드하고 싶어하지만 당신이 원하지 않는다면, 누가 이길까요? 밥이 이기고 애플리케이션이 망가지면 아무도 이기지 못합니다. 공유 인프라의 업그레이드는 무서운 일이 될 수 있습니다. 또한 최신 버전으로 구성을 업데이트하거나 업그레이드(또는 마이그레이션)하는 데 추가로 시간이 소요될 수 있으며, 이는 다시 1번 문제로 돌아가서 추가될 수 있는 비용을 살펴보는 것과 같습니다.
단 하나의 애플리케이션만 지원하도록 설계된 애플리케이션 서비스 플랫폼에 대한 필요성(수요)이 있습니다. 책임을 단일 애플리케이션으로 줄이면 구성의 크기(및 복잡성)가 줄어들고, 단일 애플리케이션의 업그레이드 실패로 인한 파급 반경이 제한되며, 인수 및 운영 비용이 절감됩니다.
클라우드, 컨테이너, 마이크로서비스 때문입니다. DevOps와 디지털 경제 덕분에 조직은 더 빠르고 더 빈번하게 결과물을 제공할 수 있게 되었습니다.
애플리케이션과 아키텍처가 변화하고 있습니다. 환경은 변화하고 있습니다. 즉, 애플리케이션 서비스와 그 제공 메커니즘도 바뀌어야 합니다.