컨테이너는 타입캐스팅에 지쳤습니다.

추수감사절과 칠면조. 크리스마스와 … 트리. 컨테이너와 … 마이크로서비스.

만약 여러분이 떠올린 각각의 첫 번째 단어가 내 기대치와 일치한다면, 여러분은 오늘날 기술 시장에서 과도한 연관성에 빠졌다는 뜻입니다. 거의 모든 토론에서 마이크로서비스와 컨테이너를 동시에 언급하는 경향이 있습니다. 그 이유는 부분적으로 애플리케이션을 집중적이고 민첩한 서비스로 분해하는 아키텍처적 접근 방식인 마이크로서비스가 컨테이너 기반 배포 모델의 민첩한 특성과 잘 맞기 때문입니다. 하지만 컨테이너 자체가 기술이라는 사실을 잊지 마세요. 마이크로서비스가 누군가의 눈에 건축적으로 반짝이기 훨씬 전부터 존재했으며 마이크로서비스 기반 앱 배포에만 유익하도록 제한되지 않습니다.

세계 최고의 반응형 애플리케이션 개발 플랫폼을 제공한다는 자칭 자랑스러운 공급업체인 Lightbend가 2,100명의 JVM 개발자를 대상으로 실시한 설문 조사인 Enterprise Development Trends 2016 의 한 내용을 살펴보겠습니다. 이 설문 조사를 통해 클라우드, 컨테이너, 마이크로서비스에 대한 많은 통찰력을 얻을 수 있었습니다. 흥미로운 점은 대부분(59%)이 완전히 새로운 애플리케이션을 컨테이너화하려고 하는 반면, 41%는 컨테이너화를 위해 "기존 애플리케이션"을 타겟으로 삼고 있다는 것입니다.

이는 전혀 이상한 일이 아닙니다. Mesosphere가 500명의 Mesos 사용자를 대상으로 2016년 8월에 실시한 설문 조사를 보면, 응답자의 51%가 Mesos에서 모놀리식 및 레거시 애플리케이션을 실행하고 있는 것으로 나타났습니다. 예상대로 85%는 마이크로서비스 아키텍처를 실행하고 있습니다.

컨테이너는 새로운 앱에만 사용되는 것이 아니라, 기존 및 모놀리식 애플리케이션도 이식성, 빠른 확장, DevOps 기반 운영과의 적합성 등 컨테이너의 많은 이점을 누릴 수 있는 수단으로 활용되고 있습니다. 결국, 우리는 원활한 이동성을 약속받았지만 각 퍼블릭 클라우드 공급업체가 서로 다른 이미징 형식을 표준화함에 따라 리이미징에 오랜 시간이 걸렸습니다. 여러 개의 골드 이미지(환경당 하나, 마이너 브랜치당 하나, 주요 브랜치당 하나... 뭐, 대충 짐작하셨겠죠?)를 유지하는 건 운영상의 악몽이 되었습니다. 꿀오소리 같은 용기는 신경 쓰지 않습니다. OS에서 OS로, 가상 머신에서 가상 머신으로, 클라우드에서 클라우드로 옮겨갈 것입니다. 그것은 눈 깜짝할 새에(계속해서 추적하고 있는 사람들을 위해 말하자면, 약 400ms) 비용 기반의 원활한 클라우드 마이그레이션의 극락조를 가능하게 하는 지금까지 제시된 가장 좋은 방법 중 하나입니다.

그래도 컨테이너를 "클라우드" 기술이라고 단정짓지 마십시오. 이를 통해 클라우드 제공업체 간의 오랫동안 기대되었지만 거의 실현되지 않았던 이동성이 가능해졌지만 클라우드나 클라우드와 유사한 환경에만 국한되지는 않습니다. Sumo Logic의 최근 보고서 에서 언급했듯이 컨테이너는 확실히 "클라우드에서" 사용되고 있으며, 이 보고서에서는 조사한 앱의 15%에서 프로덕션에서 Docker가 사용되고 있음을 발견했습니다. 하지만 그렇다고 해서 온프레미스 등 다른 곳에서 컨테이너가 사용되지 않는다는 뜻은 아닙니다. 사실, 앞서 언급한 Mesosphere 보고서는 사용자의 거의 절반(45%)이 "온프레미스 전용"이고 대부분이 "하이브리드"와 "클라우드 전용"으로 나뉜다고 언급했습니다. 흥미로운 점은 "대기업(직원 500명 이상)일수록 온프레미스를 운영할 가능성이 더 높다"는 사실도 발견됐다는 것입니다.

컨테이너는 흥미로운 배포 옵션으로, 컨테이너 오케스트레이션 솔루션(Docker, Docker Swarm, Mesos 및 Marathon, Kubernetes 등)에서 지원하는 경우 애플리케이션을 자동으로 확장하고 배포할 수 있는 매우 민첩한 환경을 제공합니다. 이는 퍼블릭 클라우드, 프라이빗 클라우드에 배포할 수 있거나, 전혀 "클라우드"가 필요하지 않은 마이크로 클라우드 또는 최소한 클라우드와 유사한 환경입니다. 컨테이너는 모놀리식 앱, 최신 앱, 마이크로서비스 기반 앱 및 API를 배포하고 확장하는 데 사용할 수 있습니다. 이러한 프레임워크는 앱이 환경에 밀접하게 결합되지 않도록 운영 체제 계층을 정규화하는 데 중점을 두기 때문에 매우 유연합니다.

간단히 말해서, 컨테이너는 앱이 허니 배저가 되어 하위 수준의 세부 사항에 대해 "관심이 없을" 수 있도록 하는 추상화 계층입니다. 컨테이너 오케스트레이션 솔루션을 통해 모니터링 및 관리되는 경우 이러한 추상화를 통해 애플리케이션 인프라 전반에서 리소스 효율성을 더욱 높이는 방식으로 자동으로 확장, 축소, 확장 및 축소할 수 있습니다.

컨테이너와 마이크로서비스와 클라우드는 서로 잘 어울리는 조합이지만, 각각 독립적으로 독립적으로 존재할 수 있는 개별 개체입니다. 각각은 서로 보완적이고, 때로는 감히 말하자면 상승효과를 갖는 이점을 제공합니다. 하지만 컨테이너를 "마이크로서비스에만", "클라우드에만"이라는 매우 좁은 틀에 갇히지 않도록 합시다.

컨테이너는 고정관념에 지쳐있습니다. 그들이 여러분의 아키텍처에서 다양한 역할을 시도하게 하면 그들이 각 역할에서 주도적인 역할을 충분히 수행할 수 있다는 것을 알게 될 것입니다.