2017.02.28

“엔터프라이즈 IT를 점검하라” 2017 컨테이너 현황

BrandPost Sponsored by HPE
David Linthicum | HPE


컨테이너는 하이프(Hype) 사이클을 넘어서는 수준으로 발전했습니다. 2017년 중앙 IT가 컨테이너에 관하여 특히, 기존 애플리케이션 마이그레이션을 고려할 때 가장 중요한 이슈입니다.

컨테이너는 이제 IT의 일부가 되었습니다. 2017년인 지금 이제 이 명제는 보편적인 사실입니다.

컨테이너의 혜택은 부정할 수 없습니다. 한때는 컨테이너가 이식성과 개발 용이성을 위한 구조자로서 홍보된 적도 있었기 때문에, 2017년에는 엔터프라이즈들이 몇 가지 현실적인 선택과 장애에 직면하게 될 것입니다. 이제는 컨테이너가 어떤 역할을 수행하고, 어떤 것이 동작하고 동작하지 않는지, 그리고 컨테이너를 적절하게 활용할 방법에 대해서 알아야 할 시기입니다. 컨테이너에 대한 축하 무대를 떠나는 지금이야말로 2017년의 컨테이너 전략이 마주할 현실에 대해 고민할 시간이기 때문입니다.

다양한 매체에 기고한 컨테이너에 대한 필자의 최근 보고서를 요약했습니다. 요약 보고서에 담은 것보다는 훨씬 더 세부적으로 고찰해봅니다. 최종 목표는 2017년에는 컨테이너 사용이 어떻게 발전할 것인가라는 관점에서 컨테이너에 대한 심층 탐색을 하는 것입니다. 이 기사에는 컨테이너 사용 지침서라기보다는 컨테이너 기술이 어느 방향으로 가고 있는지, 그리고 2017년에는 컨테이너로 어떻게 수익을 낼 것인지에 대한 내용을 담았습니다.

2016년의 컨테이너 실적은?
첫째, 컨테이너가 내건 공약을 되돌아보고, 2016년에 얼마나 기대에 부응했는지를 살펴봅시다.

약속
컨테이너 추상화를 활용함으로써 복잡성 축소
현실
컨테이너가 클라우드 기반 서버 같은 호스트 플랫폼으로부터 벗어날 수 있게 해 줄 거라는 생각이었지만, 여전히 자체만으로도 복합할 수 있는 컨테이너들로 이루어진 플랫폼과 씨름해야만 합니다.

약속
컨테이너의 이식성을 극대화하고 그렇게 해서 가치를 극대화 시키기 위해 컨테이너에 자동화를 활용
현실
대부분의 경우, 이 약속은 잘 동작했습니다. 그렇지만, 대부분의 이식 시험은 개념 증명이어서, 아주 새로운 애플리케이션에 대해서 수행되었습니다.

약속
서비스를 컨테이너 내부가 아닌 컨테이너를 중심으로 배치함으로써 더 나은 보안과 거버넌스 제공
현실
시장에 진입한 보안과 거버넌스 도구들은 이 약속을 충족했습니다. 그렇지만, 엔터프라이즈들이 보안 처리를 담당해서, 자동화되지도 편리하지도 않은 결과를 냈습니다.

약속
애플리케이션을 동일한 컨테이너 내부에 모두 존재하는 여러 상이한 도메인으로 나눌 수 있기 때문에 더 나은 분산 컴퓨팅 기능을 제공
현실
컨테이너를 활용하기 위해서는 애플리케이션을 분산시키기 위해 나누는 것처럼, 애플리케이션의 아키텍처를 새로 구성할 필요가 있습니다. 아주 새로운 애플리케이션에는 적합했지만, 컨테이너가 존재하기 이전에 개발된 기존 애플리케이션에 대해서는 그리 좋지 않았습니다.

약속
정책 기반의 최적화 그리고 자동 구성(Self-configuration)을 포함한 자동 서비스 제공
현실
컨테이너가 가장 효능을 발휘한 부분입니다. 컨테이너는 정말로 최적화와 자동 구성을 제공했으며, 구글의 퀴베르네시스(Kubernetes) 같은 컨테이너 클러스터 관리자와 결합할 때 훨씬 더 잘해냈습니다.

위의 비교에서 볼 수 있듯, 대부분의 컨테이너 공약은 잘 지켜졌습니다. 다른 많은 기술이 달성한 것보다 더 나은 결과를 냈습니다! 컨테이너는 정말로 이식성을 제공했으며, 클러스터 관리자와 함께 확장할 수 있으며 엔터프라이즈급 성능을 제공할 수 있습니다. 그렇기는 하지만, 기존 애플리케이션과는 잘 맞지 않아서 “컨테이너화” 시키려면 거의 항상, 어느 정도의 대수술이 필요한 것이 사실입니다.

2017년의 애플리케이션 컨테이너화
자, 더 중요한 질문은 이것입니다. “2017년에는 컨테이너가 기존 애플리케이션을 현대화할 수 있는 기능을 제공할 것인가?”

이 질문에 답을 하기 위해서는, 아래 표를 검토해야 합니다. 밑의 표는 애플리케이션을 클라우드로 이전하기 위한 3가지 유형의 주요 접근방식에서 필요한 몇 가지 특징을 고려합니다.

컨테이너로 이전
리팩토
(Refactor: 코드 재 작성) (목표 클라우드에 맞게 애플리케이션의 일부 또는 전체 코드를 재 작성)
그대로 이전(Lift and Shift) (아무런 수정 없이 애플리케이션을 이전)

이런 접근방식 안에서, 이 표에 나열된 모든 것을 포함하는 다음과 같은 와해 지수(Disruptive Vector)를 고려합니다.

표 1: 가중치가 부여된 와해 지수

이 표는 대부분의 엔터프라이즈가 중요하다고 생각하는 것을 근거로 가중치를 부여하고 있지만, 조직마다 조금 다를 수 있습니다. 조직에 맞춰 세부 사항을 조정하십시오. 가중치를 부여하면 이런 지수를 컨테이너화를 포함한 3가지 유형의 애플리케이션 이전 방식과 비교하고 대조할 수 있습니다.

표 2: 엔터프라이즈 사용도에 따른 순위 제공

순위는 각각의 지수에 대한 점수를 제공하기 위해 와해 지수를 사용하여 위의 가중치에 기반을 둡니다.

- 코드와 데이터 이식성(Code and data portability) 컨테이너 내부 또는 외부에 존재하는지에 관계없이, 코드와 데이터를 원래 플랫폼에서 목표 플랫폼으로 이식하기 위한 능력을 의미합니다. 정확하게 수행된다면, 컨테이너는 코드를 수정하거나 데이터의 구조를 수정하지 않고 한 플랫폼에서 다른 플랫폼으로 이동할 수 있을 것입니다.

- 클라우드 고유 특징(Cloud native features) 호스트 클라우드 플랫폼의 특징과 기능을 활용할 수 있다는 의미입니다. 이 경우, 그런 특정 기능들을 활용하도록 애플리케이션을 작성했다는 점을 고려하면 리팩토링이 더 강력한 접근방식입니다.

- 플리케이션과 데이터 성능(Application and data performance) 컨테이너와 리팩토링 간에서는 실제로 거의 같지만, 목표 플랫폼이나 클라우드 상의 성능에 대한 어떤 최적화도 하지 않는다는 점을 고려하면 ‘그대로 이전’ 방식에서는 매우 열악합니다.

- 서비스 사용도(Use of services) 네이티브 클라우드 서비스를 다루고 있다는 점을 고려하면, 컨테이너와 리팩토링에서 매우 강력한 요소입니다.

거버넌스와 보안(Governance and security) 항목에 대해서도 거의 동일한 문제가 나타납니다. 역시 컨테이너와 리팩토링이 호스트 플랫폼에 더 가까우며, 그런 이유로 보안과 거버넌스 서비스도 활용할 수 있습니다.

마지막으로, 비즈니스 민첩성(Business agility)은 조직이 쉽게 변경과 확장하는 정도를 말합니다. 일단 구축되고 나면, 자신들이 구동하는 플랫폼을 확장시키거나 변경할 수 있다는 의미에서 컨테이너에 적용된다고 할 수 있습니다.

물론, 대부분의 엔터프라이즈가 고려하고 있는 가장 큰 문제는 비용입니다. (도커 같은)컨테이너를 활용하는 애플리케이션을 구축하기 위한 비용과 리팩토링을 하기 위한 비용이 거의 같습니다. 두 가지 모두 침해적이기 때문에 비용과 위험을 수반합니다.
 

 



2017.02.28

“엔터프라이즈 IT를 점검하라” 2017 컨테이너 현황

BrandPost Sponsored by HPE
David Linthicum | HPE


컨테이너는 하이프(Hype) 사이클을 넘어서는 수준으로 발전했습니다. 2017년 중앙 IT가 컨테이너에 관하여 특히, 기존 애플리케이션 마이그레이션을 고려할 때 가장 중요한 이슈입니다.

컨테이너는 이제 IT의 일부가 되었습니다. 2017년인 지금 이제 이 명제는 보편적인 사실입니다.

컨테이너의 혜택은 부정할 수 없습니다. 한때는 컨테이너가 이식성과 개발 용이성을 위한 구조자로서 홍보된 적도 있었기 때문에, 2017년에는 엔터프라이즈들이 몇 가지 현실적인 선택과 장애에 직면하게 될 것입니다. 이제는 컨테이너가 어떤 역할을 수행하고, 어떤 것이 동작하고 동작하지 않는지, 그리고 컨테이너를 적절하게 활용할 방법에 대해서 알아야 할 시기입니다. 컨테이너에 대한 축하 무대를 떠나는 지금이야말로 2017년의 컨테이너 전략이 마주할 현실에 대해 고민할 시간이기 때문입니다.

다양한 매체에 기고한 컨테이너에 대한 필자의 최근 보고서를 요약했습니다. 요약 보고서에 담은 것보다는 훨씬 더 세부적으로 고찰해봅니다. 최종 목표는 2017년에는 컨테이너 사용이 어떻게 발전할 것인가라는 관점에서 컨테이너에 대한 심층 탐색을 하는 것입니다. 이 기사에는 컨테이너 사용 지침서라기보다는 컨테이너 기술이 어느 방향으로 가고 있는지, 그리고 2017년에는 컨테이너로 어떻게 수익을 낼 것인지에 대한 내용을 담았습니다.

2016년의 컨테이너 실적은?
첫째, 컨테이너가 내건 공약을 되돌아보고, 2016년에 얼마나 기대에 부응했는지를 살펴봅시다.

약속
컨테이너 추상화를 활용함으로써 복잡성 축소
현실
컨테이너가 클라우드 기반 서버 같은 호스트 플랫폼으로부터 벗어날 수 있게 해 줄 거라는 생각이었지만, 여전히 자체만으로도 복합할 수 있는 컨테이너들로 이루어진 플랫폼과 씨름해야만 합니다.

약속
컨테이너의 이식성을 극대화하고 그렇게 해서 가치를 극대화 시키기 위해 컨테이너에 자동화를 활용
현실
대부분의 경우, 이 약속은 잘 동작했습니다. 그렇지만, 대부분의 이식 시험은 개념 증명이어서, 아주 새로운 애플리케이션에 대해서 수행되었습니다.

약속
서비스를 컨테이너 내부가 아닌 컨테이너를 중심으로 배치함으로써 더 나은 보안과 거버넌스 제공
현실
시장에 진입한 보안과 거버넌스 도구들은 이 약속을 충족했습니다. 그렇지만, 엔터프라이즈들이 보안 처리를 담당해서, 자동화되지도 편리하지도 않은 결과를 냈습니다.

약속
애플리케이션을 동일한 컨테이너 내부에 모두 존재하는 여러 상이한 도메인으로 나눌 수 있기 때문에 더 나은 분산 컴퓨팅 기능을 제공
현실
컨테이너를 활용하기 위해서는 애플리케이션을 분산시키기 위해 나누는 것처럼, 애플리케이션의 아키텍처를 새로 구성할 필요가 있습니다. 아주 새로운 애플리케이션에는 적합했지만, 컨테이너가 존재하기 이전에 개발된 기존 애플리케이션에 대해서는 그리 좋지 않았습니다.

약속
정책 기반의 최적화 그리고 자동 구성(Self-configuration)을 포함한 자동 서비스 제공
현실
컨테이너가 가장 효능을 발휘한 부분입니다. 컨테이너는 정말로 최적화와 자동 구성을 제공했으며, 구글의 퀴베르네시스(Kubernetes) 같은 컨테이너 클러스터 관리자와 결합할 때 훨씬 더 잘해냈습니다.

위의 비교에서 볼 수 있듯, 대부분의 컨테이너 공약은 잘 지켜졌습니다. 다른 많은 기술이 달성한 것보다 더 나은 결과를 냈습니다! 컨테이너는 정말로 이식성을 제공했으며, 클러스터 관리자와 함께 확장할 수 있으며 엔터프라이즈급 성능을 제공할 수 있습니다. 그렇기는 하지만, 기존 애플리케이션과는 잘 맞지 않아서 “컨테이너화” 시키려면 거의 항상, 어느 정도의 대수술이 필요한 것이 사실입니다.

2017년의 애플리케이션 컨테이너화
자, 더 중요한 질문은 이것입니다. “2017년에는 컨테이너가 기존 애플리케이션을 현대화할 수 있는 기능을 제공할 것인가?”

이 질문에 답을 하기 위해서는, 아래 표를 검토해야 합니다. 밑의 표는 애플리케이션을 클라우드로 이전하기 위한 3가지 유형의 주요 접근방식에서 필요한 몇 가지 특징을 고려합니다.

컨테이너로 이전
리팩토
(Refactor: 코드 재 작성) (목표 클라우드에 맞게 애플리케이션의 일부 또는 전체 코드를 재 작성)
그대로 이전(Lift and Shift) (아무런 수정 없이 애플리케이션을 이전)

이런 접근방식 안에서, 이 표에 나열된 모든 것을 포함하는 다음과 같은 와해 지수(Disruptive Vector)를 고려합니다.

표 1: 가중치가 부여된 와해 지수

이 표는 대부분의 엔터프라이즈가 중요하다고 생각하는 것을 근거로 가중치를 부여하고 있지만, 조직마다 조금 다를 수 있습니다. 조직에 맞춰 세부 사항을 조정하십시오. 가중치를 부여하면 이런 지수를 컨테이너화를 포함한 3가지 유형의 애플리케이션 이전 방식과 비교하고 대조할 수 있습니다.

표 2: 엔터프라이즈 사용도에 따른 순위 제공

순위는 각각의 지수에 대한 점수를 제공하기 위해 와해 지수를 사용하여 위의 가중치에 기반을 둡니다.

- 코드와 데이터 이식성(Code and data portability) 컨테이너 내부 또는 외부에 존재하는지에 관계없이, 코드와 데이터를 원래 플랫폼에서 목표 플랫폼으로 이식하기 위한 능력을 의미합니다. 정확하게 수행된다면, 컨테이너는 코드를 수정하거나 데이터의 구조를 수정하지 않고 한 플랫폼에서 다른 플랫폼으로 이동할 수 있을 것입니다.

- 클라우드 고유 특징(Cloud native features) 호스트 클라우드 플랫폼의 특징과 기능을 활용할 수 있다는 의미입니다. 이 경우, 그런 특정 기능들을 활용하도록 애플리케이션을 작성했다는 점을 고려하면 리팩토링이 더 강력한 접근방식입니다.

- 플리케이션과 데이터 성능(Application and data performance) 컨테이너와 리팩토링 간에서는 실제로 거의 같지만, 목표 플랫폼이나 클라우드 상의 성능에 대한 어떤 최적화도 하지 않는다는 점을 고려하면 ‘그대로 이전’ 방식에서는 매우 열악합니다.

- 서비스 사용도(Use of services) 네이티브 클라우드 서비스를 다루고 있다는 점을 고려하면, 컨테이너와 리팩토링에서 매우 강력한 요소입니다.

거버넌스와 보안(Governance and security) 항목에 대해서도 거의 동일한 문제가 나타납니다. 역시 컨테이너와 리팩토링이 호스트 플랫폼에 더 가까우며, 그런 이유로 보안과 거버넌스 서비스도 활용할 수 있습니다.

마지막으로, 비즈니스 민첩성(Business agility)은 조직이 쉽게 변경과 확장하는 정도를 말합니다. 일단 구축되고 나면, 자신들이 구동하는 플랫폼을 확장시키거나 변경할 수 있다는 의미에서 컨테이너에 적용된다고 할 수 있습니다.

물론, 대부분의 엔터프라이즈가 고려하고 있는 가장 큰 문제는 비용입니다. (도커 같은)컨테이너를 활용하는 애플리케이션을 구축하기 위한 비용과 리팩토링을 하기 위한 비용이 거의 같습니다. 두 가지 모두 침해적이기 때문에 비용과 위험을 수반합니다.
 

 



X