클라우드로의 Lift and Shift 성공을 위해 아키텍처에 집중

"클라우드 전환"에는 두 가지 뚜렷한 모델이 등장했습니다. 첫 번째로 가장 분명한 것은 토착적 접근 방식입니다. 네이티브는 새로운 것을 의미하며 그린필드이든 다시 쓴 것이든 상관없습니다. 네이티브 방식은 애플리케이션에만 집중하는 경향이 있으며, 클라우드에 맞게 조정하면 성능과 보안이 클라우드에서 적절한 서비스를 프로비저닝하는 문제라는 가정을 합니다. 전적으로 사실은 아니지만 지금은 그 주장이 거의 맞다고 생각합니다.

두 번째 접근 방식은 "리프트 앤 시프트"로, 말 그대로의 의미에 초점을 맞춥니다. 기존 애플리케이션을 데이터 센터 기반에서 들어올려 클라우드로 옮겨 클라우드 기반에 배치하는 것입니다. 하지만 이 모델에서는 애플리케이션에만 초점을 맞출 수 없습니다. 애플리케이션에도 해결해야 할 종속성이 있기 때문입니다. 여기에는 애플리케이션과 인프라 서비스에 걸쳐 있는 기타 아키텍처 구성 요소가 포함됩니다. 

이는 최근 Cloud Velox 보고서 에서 강조되었는데, 여기서는 클라우드를 2차 데이터 센터로 활용하는 것에 초점을 맞췄습니다. 흥미롭게도 다음과 같은 결과가 발견되었습니다.

Cloud Velox는 재해 복구에 초점을 맞추고 있었지만, 일반적인 문제가 더 광범위하게 적용되는 것 같습니다. 앱을 클라우드로 리프트 앤 시프트하는 것은 네트워크 및 보안 제어(서비스)도 함께 리프트 앤 시프트할 수 있다면 훨씬 더 수용 가능합니다.

기본적으로, 앱 서비스 없이 네트워크에 호스팅된 앱 서비스를 사용하여 수년에 걸쳐 최적화된 앱을 옮기면 해당 최적화가 손실됩니다. 아, 그저 클라우드에 있기만 해도 성능이 향상된다는 잘못된 믿음이 있습니다. 인터넷 백본과 이와 상호 작용하는 사용자에 물리적으로 더 가깝기 때문입니다. 어느 정도 사실이지만 전적으로 그런 것은 아닙니다. 그 이유는 애플리케이션 성능의 대부분이 네트워크 지연에 의해 결정되지 않기 때문입니다. 진실은 성능 저하로 이어지는 애플리케이션의 비효율성 중 상당수가 콘텐츠 크기와 구성, 연결 관리 불량, 네트워크 스택을 애플리케이션의 특정 요구 사항에 맞게 적절히 조정할 수 없는 것과 관련이 있다는 것입니다.

보안 문제 역시 앱을 클라우드로 옮겨도 갑자기 사라지지 않습니다. 데이터 센터에서 앱이 XSS 또는 SQLi에 취약한 경우 클라우드로 옮길 때도 여전히 취약할 가능성이 높습니다.*  해당 문제가 웹 앱 방화벽이나 프로그래밍 가능 프록시에 배포된 보안 아티팩트를 통해 데이터 센터에서 해결된다면, 앱 방화벽과 프록시도 앱과 함께 옮겨놓는 것이 가장 좋습니다.

애플리케이션만이 아니라 아키텍처를 "리프트 앤 시프트"할 수 있는 기능은 공동 배치 클라우드 옵션의 인기가 높아지는 이유 중 하나입니다. 온프레미스에 비해 비용이 절감되고 클라우드보다 제어가 더 뛰어나다는 주장도 있지만, 공동 배치 클라우드 옵션의 더 매력적인 특징 중 하나는 전체 아키텍처를 리프트 앤 시프트 하고 "옆집 클라우드"의 이점을 활용할 수 있다는 것입니다. 때로는 조직에서 성능을 저하시키는 지연 시간을 피하기 위해 데이터 소스를 클라우드에 배포된 앱에 더 가깝게 옮기고 싶어하는데, 이는 기업 데이터 센터까지 다시 전송하는 데 필요합니다. 때로는 기업에서 백엔드를 방해하지 않고 프런트엔드를 확장할 수 있어야 하며(또한 지연 시간을 방지해야 함) 공동 배치된 클라우드 제공업체로 이전한다는 것은 클라우드가 바로 거기에 있고, 매우 빠른 데이터 센터 수준의 상호 연결을 통해 이루어지기 때문에 가능하다는 것을 의미합니다.

클라우드에 대한 접근 방식(코로케이션 또는 퍼블릭)에 관계없이 클라우드로의 성공적인 리프트 앤 시프트의 핵심은 가능한 한 많은 아키텍처를 리프트 앤 시프트하는 것입니다. 클라우드 서비스 옵션이 없더라도 성능과 보안이 이전으로 인해 손상되지 않도록 하기 위해 전환 중에도 중요한 앱 서비스를 해당 애플리케이션과 함께 유지하는 것이 중요합니다. 

* 호프의 법칙 이라고도 불리며, 실제로 법칙은 아니지만 2009년 처음 관찰되었을 때와 마찬가지로 오늘날에도 정확한 관찰로 남아 있습니다.