애플리케이션 현대화는 기존 레거시 애플리케이션을 가져와서 해당 플랫폼 인프라, 내부 아키텍처 및/또는 기능을 현대화하는 프로세스입니다. 오늘날 애플리케이션 현대화에 대해서는 일반적으로 폭포수 개발 프로세스를 사용하여 업데이트되고 유지보수되는 모놀리식 온프레미스 애플리케이션과, 그러한 애플리케이션을 클라우드 아키텍처 및 릴리스 패턴, 즉 마이크로서비스 및 DevOps에 어떻게 적용할 수 있는지를 중점적으로 다루는 논의가 주를 이루고 있습니다.

애플리케이션 현대화의 이점은 일반적으로 새로운 기능을 더 빠르게 제공하고, 다른 서비스에서 API를 통해 사용할 수 있도록 기존 애플리케이션의 기능을 노출하며, 데이터 센터와 IT의 장기적 전략뿐만 아니라 애플리케이션 규모와 성능을 위해 온프레미스에서 클라우드로 애플리케이션의 플랫폼을 이동하는 것으로 요약할 수 있습니다.

이러한 애플리케이션 현대화의 문제는 결국 비용과 복잡성으로 귀결됩니다. ROI를 고려하지 않고 온프레미스 환경의 애플리케이션을 클라우드로 이동하는 것은 그저 이동을 위한 애플리케이션 이동에 불과합니다. 반면에, 플랫폼 이동 또는 재설계로 상당한 이점을 누리는 애플리케이션도 기존 시스템 및 인프라와 밀접하게 연결되어 있어 애플리케이션 현대화로 인한 복잡성이 그 이점을 능가할 수도 있습니다.

대부분 그렇듯이 애플리케이션 현대화에서 성공의 열쇠는 결국 애플리케이션 현대화의 전략과 프로젝트의 선택에 달려 있습니다. 애플리케이션 측면에서 클라우드, 속도, 성능, 확장성, 새로운 기능 개발 등의 이점이 고객 환경 및 ROI 개선을 위한 명확한 길로 이어지는 전략과 프로젝트여야 합니다.

레거시 애플리케이션은 모놀리식 애플리케이션인 경우가 많습니다. 모놀리식 애플리케이션은 업데이트가 쉽지 않으며 확장 역시 비용이 많이 들고 어렵기 때문에 현대화하는 것이 좋습니다.

모놀리식 앱은 구조적인 이유로 인해 업데이트가 쉽지 않습니다. 애플리케이션의 모든 구성요소가 함께 제공되기 때문에 복잡성과 통합 문제의 간접 비용을 고려하면 기능을 추가하는 일은 어렵고 비용이 많이 듭니다.

이와 비슷한 이유로 확장하는 데도 어려움이 있으며 비용이 많이 듭니다. 앱의 1개 컴포넌트에서 로드 및 성능 문제가 발생한 경우, 단지 가장 처리량이 많은 이 1개의 컴포넌트를 처리하기 위해 전체 앱을 확장해야 할 수 있습니다. 이러한 접근 방식은 고비용의 컴퓨팅을 수반합니다.

더 많은 마이크로서비스 아키텍처로 애플리케이션을 현대화하면 구성요소가 더 작고 느슨하게 결합되고 서로 독립적으로 배치 및 확장될 수 있습니다. 이 접근 방식은 고유한 문제점들이 있긴 하지만 현대화의 핵심 가치 대부분을 보여줍니다.

다음 동영상에서는 마이크로서비스 아키텍처에 대해 자세히 설명합니다.

애플리케이션 현대화 프로젝트는 애플리케이션 평가로 시작하는 것이 가장 중요합니다. 보유 중인 애플리케이션의 목록을 작성하는 것이 이러한 변환을 시작하는 가장 명확한 방법 중 하나라고 할 수 있습니다.

목록을 작성한 후에는 x축에 난이도를, y축에 잠재적 가치 증가를 기준으로 두어 이러한 모든 애플리케이션을 도식화할 수 있습니다. 또한 애플리케이션의 "잠재적" 가치에 고객 경험과 조직의 미래에 대한 중요성을 포함시킬 수도 있습니다.

가치는 높고 난이도는 낮은, 그래프 오른쪽 상단의 사분면에 속하는 애플리케이션이 애플리케이션 현대화 프로젝트를 시작할 수 있는 가장 명확하고 논쟁이 적은 후보가 될 것입니다.

이동이 어려운 높은 가치의 앱이 시작을 결정하기가 가장 어렵습니다. 이러한 경우, 이는 또한 첫날에 모 아니면 도 전략일 필요가 없습니다. 즉, 포트폴리오를 바람직한 방향으로 이동하면서 위험과 비용을 줄일 수 있는 애플리케이션 현대화 방법이 있습니다.

플랫폼, 애플리케이션 아키텍처, API를 통한 애플리케이션의 기능 노출의 조합에 중점을 둔 애플리케이션 현대화에 대한 몇 가지 잘 알려진 접근 방식이 있습니다.

모놀리식에서 마이크로서비스로 전환. 애플리케이션 현대화의 가장 일반적인 패턴은 모놀리식 애플리케이션을 작고 느슨하게 결합된 마이크로서비스 콜렉션으로 재구성 및 세분화하는 것입니다.

위의 마이크로서비스 아키텍처 예에서  소매 애플리케이션은 단일 n계층 애플리케이션에서 애플리케이션 내의 모든 개별 서비스의 마이크로서비스 콜렉션으로 세분화되었으며, 각 개별 서비스는 데이터베이스와 데이터 모델을 사용합니다.

이러한 경우 적용할 수 있는 접근 방식 중 하나가 "스트랭글러 패턴"입니다. 스트랭글러 패턴은 모놀리식 애플리케이션을 한 번에 모두 분해하지 않고 조금씩 분해하여 가장 쉽고 가장 가치 있는 부분을 먼저 시작하는 방식으로 진행함으로써 결국 모놀리식에 아무것도 남지 않게 됩니다.

클라우드 마이그레이션. 마이크로서비스 재구성, 애플리케이션 플랫폼 이동 또는 재호스팅은 거의 모든 현대화 프로세스의 일부가 되고 있습니다. 사실상 재작성 작업을 많이 하지 않으면서 애플리케이션을 단순히 들어 올려 이동하는 것이 가능하지만, 컨테이너 및 Kubernetes를 활용하여 클라우드 모델을 더 잘 활용할 수 있도록 애플리케이션을 재구성하는 것이 더 가치있는 경우가 많습니다. (클라우드 마이그레이션 자세히 보기)

API를 통한 기능 노출

마지막으로, 현대화를 위한 또 다른 접근 방식은 애플리케이션을 현재 위치에 그대로 남겨두되 API를 통해 해당 기능이나 데이터를 안전하게 노출시키는 것입니다. 마이그레이션보다 통합에 더 많은 비중을 두는 이러한 접근 방식은 새로운 클라우드 네이티브 애플리케이션이 기존 시스템과 데이터의 기능을 간편하게 활용할 수 있도록 해줍니다.

대부분의 기업들에서 검토 중인 현대화 프로세스를 앞당길 수 있는 광범위한 기술 포트폴리오가 있습니다.

프라이빗 클라우드, 하이브리드 클라우드 및 멀티클라우드

퍼블릭 클라우드가 현대화 전략의 중요 부분이긴 하지만, 프라이빗 클라우드, 하이브리드 클라우드 및 멀티클라우드 전략 또한 보안, 대기 시간 및 아키텍처 상의 이유로 매우 중요합니다.

여러 가지 이유로 인해 기업은 데이터 센터에서 퍼블릭 클라우드로 바로 전환할 준비가 되어 있지 않을 수 있으며, 다른 클라우드 모델이 고유한 특성을 기반으로 특정 워크로드가 상주해야 하는 모든 관련 아키텍처 및 정책의 복잡성을 해결하는 데 도움이 될 수 있습니다.

컨테이너 및 Kubernetes

컨테이너 및 Kubernetes는 클라우드의 다목적 컴퓨팅 형태로서 가상 머신(VM)에 대한 도전이자 하이브리드 클라우드 및 애플리케이션 현대화 전략의 핵심 요소로 부상했습니다.

컨테이너화를 사용하면 데스크탑, 클라우드 또는 온프레미스 환경에서 일관되게 실행할 수 있도록 애플리케이션을 일관성 있는 경량의 방식으로 패키징할 수 있습니다. 이러한 유형의 유연성은 클라우드에서 향후 계획을 설계 중인 기업들에게 실질적인 도움이 됩니다.