2020.07.29

IDG 블로그 | 애플리케이션 마이그레이션, 회색 음영을 살펴라

David Linthicum | InfoWorld
클라우드로 이전할 애플리케이션의 리팩터링에서 클라우드 네이티브의 필요성을 강하게 주장했지만, 현실은 그렇게 흑백으로 나뉘지 않는다.

애플리케이션을 퍼블릭 클라우드로 이전하는 일반적인 접근법은 클라우드 네이티브 기능의 이점을 활용할 수 있도록 애플리케이션을 수정하는 것이다. 애플리케이션이 클라우드 네이티브 관리 시스템, 보안 시스템, 기타 네이티브 서비스와 이야기할 수 있도록 하는 것이다.

대안으로 리프트 앤 시프트 방식이 있다. 가능한 한 애플리케이션을 거의 수정하지 않고 이전하는 방식이다. 이 경우, 클라우드 네이티브 기능을 함께 이용하는 것은 포기해야 한다.
 
ⓒ Getty Images Bank

베스트 프랙티스는 양쪽 극단의 접근법, 즉 클라우드 네이티브에 올인하거나 전혀 이용하지 않는 두 가지로 나뉘어 나타났다. 하지만 현실은 이렇게 양분된 결정이 아니며, 많은 기업이 찾는 해답은 스펙트럼에 걸쳐 동작하는 것이 될 수도 있다.

첫째, 우리는 애플리케이션이 서로 다른 비즈니스 문제를 해결하기 위해 서로 다른 목적으로 만들어졌다는 것을 잘 알고 있다. 이런 애플리케이션의 리팩터링에 모든 문제를 해결하는 만능 해법식 접근을 하는 것은 현실적이지 않다는 것도 이미 알고 있다. 

둘째, 많은 기업이 자사의 목적을 고려해 애플리케이션의 올바른 리팩터링 접근 방안을 골라야 한다는 사실을 모른다. 애플리케이션 마이그레이션이 실패하는 주된 이유이기도 하다.

필자가 가장 자주 보는 실수는 범용적인 접근법을 선택하는 것이다. 애플리케이션의 기능성을 살펴보지도 않고, 모든 애플리케이션에 클라우드 네이티브 보안과 암호화가 필요하다고 결정해 버린다. 하지만 정작 해당 애플리케이션은 클라우드 네이티브 관리 서비스도 AI나 서버리스, 머신러닝 같은 떠오르는 기술도 이용할 필요가 없다.

이런 일은 편의성 때문에 일어난다. 개발자에게 특정 기능을 일관성 있게 사용하고 나머지는 신경 쓰지 말라고 하는 것이 훨씬 쉽기 때문이다. 더 적은 자체 기술력과 더 적은 툴로 버틸 수 있고, 그래서 개발 비용도 낮출 수 있다. 하지만 이렇게 하면 기업 애플리케이션의 약 75%는 이전하려는 퍼블릭 클라우드에 최적화되지 못한다.

그런데, 최적화가 부족한지는 잘 드러나지 않는다. 이런 비효율성을 파악하고 비용을 이해하고 100% 효율적인 환경이 되도록 권고안을 만들기 위해서는 전문적인 분석 작업이 필요하다. 애플리케이션의 요구사항과 클라우드 네이티브 서비스의 올바른 조합을 이용하는 역량 간에 균형을 맞춰야 한다. 이 방식은 운영 비용을 낮추고 비즈니스 관점의 애플리케이션 가치를 확실하게 높여준다.

지금의 현실은 애플리케이션을 클라우드로 이전할 때 똑같이 취급하지 않는다는 것이다. 어떤 기업은 전면적인 클라우드 네이티브를 원할 것이고, 어떤 기업은 전혀 사용하지 않을 것이다. 게다가 언제 무엇을 해야 하는지에 대한 확고한 규칙도 없다. 결국 각 애플리케이션의 필요에 딱 맞는 클라우드 네이티브 서비스는 무엇인가의 관점에서 애플리케이션을 이해해야 한다. 그야말로 ‘회색 음영’이 될지도 모른다. editor@itworld.co.kr


2020.07.29

IDG 블로그 | 애플리케이션 마이그레이션, 회색 음영을 살펴라

David Linthicum | InfoWorld
클라우드로 이전할 애플리케이션의 리팩터링에서 클라우드 네이티브의 필요성을 강하게 주장했지만, 현실은 그렇게 흑백으로 나뉘지 않는다.

애플리케이션을 퍼블릭 클라우드로 이전하는 일반적인 접근법은 클라우드 네이티브 기능의 이점을 활용할 수 있도록 애플리케이션을 수정하는 것이다. 애플리케이션이 클라우드 네이티브 관리 시스템, 보안 시스템, 기타 네이티브 서비스와 이야기할 수 있도록 하는 것이다.

대안으로 리프트 앤 시프트 방식이 있다. 가능한 한 애플리케이션을 거의 수정하지 않고 이전하는 방식이다. 이 경우, 클라우드 네이티브 기능을 함께 이용하는 것은 포기해야 한다.
 
ⓒ Getty Images Bank

베스트 프랙티스는 양쪽 극단의 접근법, 즉 클라우드 네이티브에 올인하거나 전혀 이용하지 않는 두 가지로 나뉘어 나타났다. 하지만 현실은 이렇게 양분된 결정이 아니며, 많은 기업이 찾는 해답은 스펙트럼에 걸쳐 동작하는 것이 될 수도 있다.

첫째, 우리는 애플리케이션이 서로 다른 비즈니스 문제를 해결하기 위해 서로 다른 목적으로 만들어졌다는 것을 잘 알고 있다. 이런 애플리케이션의 리팩터링에 모든 문제를 해결하는 만능 해법식 접근을 하는 것은 현실적이지 않다는 것도 이미 알고 있다. 

둘째, 많은 기업이 자사의 목적을 고려해 애플리케이션의 올바른 리팩터링 접근 방안을 골라야 한다는 사실을 모른다. 애플리케이션 마이그레이션이 실패하는 주된 이유이기도 하다.

필자가 가장 자주 보는 실수는 범용적인 접근법을 선택하는 것이다. 애플리케이션의 기능성을 살펴보지도 않고, 모든 애플리케이션에 클라우드 네이티브 보안과 암호화가 필요하다고 결정해 버린다. 하지만 정작 해당 애플리케이션은 클라우드 네이티브 관리 서비스도 AI나 서버리스, 머신러닝 같은 떠오르는 기술도 이용할 필요가 없다.

이런 일은 편의성 때문에 일어난다. 개발자에게 특정 기능을 일관성 있게 사용하고 나머지는 신경 쓰지 말라고 하는 것이 훨씬 쉽기 때문이다. 더 적은 자체 기술력과 더 적은 툴로 버틸 수 있고, 그래서 개발 비용도 낮출 수 있다. 하지만 이렇게 하면 기업 애플리케이션의 약 75%는 이전하려는 퍼블릭 클라우드에 최적화되지 못한다.

그런데, 최적화가 부족한지는 잘 드러나지 않는다. 이런 비효율성을 파악하고 비용을 이해하고 100% 효율적인 환경이 되도록 권고안을 만들기 위해서는 전문적인 분석 작업이 필요하다. 애플리케이션의 요구사항과 클라우드 네이티브 서비스의 올바른 조합을 이용하는 역량 간에 균형을 맞춰야 한다. 이 방식은 운영 비용을 낮추고 비즈니스 관점의 애플리케이션 가치를 확실하게 높여준다.

지금의 현실은 애플리케이션을 클라우드로 이전할 때 똑같이 취급하지 않는다는 것이다. 어떤 기업은 전면적인 클라우드 네이티브를 원할 것이고, 어떤 기업은 전혀 사용하지 않을 것이다. 게다가 언제 무엇을 해야 하는지에 대한 확고한 규칙도 없다. 결국 각 애플리케이션의 필요에 딱 맞는 클라우드 네이티브 서비스는 무엇인가의 관점에서 애플리케이션을 이해해야 한다. 그야말로 ‘회색 음영’이 될지도 모른다. editor@itworld.co.kr


X