네, 그렇죠. 일어나고 있어요. 그 과정을 덜 번거롭게 만들려면 이를 포괄적인 클라우드 전략의 일부로 만드는 것을 고려하세요.
다음의 공통점은 무엇입니까? 연어, 캐나다 거위, 군주 나비 및 응용 프로그램.
이 모든 것이 한 장소에서 다른 장소로 이동한다고 추측했다면, 자화자찬입니다.
일반적으로 클라우드 마이그레이션에 대해 이야기할 때는 온프레미스에서 오프프레미스로의 마이그레이션을 말합니다. 그럴 만한 이유가 있습니다. 퍼블릭 클라우드 사용 채택이 증가하고 있음을 나타내는 많은 데이터( 저희 데이터 포함 )가 있습니다. 우리가 거의 언급하지 않는 것은 역방향으로 발생하는 이주입니다. 지금은 "이단!"이라는 외침이 들리는 듯하지만 현실적으로 생각해 봅시다. 이런 일은 발생하며 여러분이 생각하는 것보다 더 자주 발생합니다.
예를 들어:
프로덕션에서 퍼블릭 IaaS를 채택한 응답자의 42%는 " 향후 4년 이내 또는 지속적인 프로세스로 현재 전략에서 마이그레이션할 계획 "이라고 밝혔습니다. " 전적으로 프라이빗 클라우드 솔루션으로 전환하기보다는 하이브리드 클라우드로 전환할 것으로 예상 "하는 사람은 70%에 달했습니다.
그 이유는? 가장 흔한 요인은 비용 절감(67%)이었고, 그 다음으로는 보안 및 안정성이었습니다. 이는 Pubmatic이 퍼블릭 클라우드에서 프라이빗 클라우드로 마이그레이션한 것과 같은 사례에서 입증됩니다. 비용이 주요 원인이었습니다.
하지만 우리가 들어본 대로, 다른 사람들은 반대 방향으로 이주하고 있습니다. 많이. 개인 IaaS 플랫폼을 사용하는 사람 중 57%는 " 공용 또는 하이브리드 클라우드로 마이그레이션할 계획"이며, 응답자의 77%는 하이브리드 방식을 채택할 계획이라고 밝혔습니다.
그들의 논리는? 확장성(71%)이 가장 높고 그 다음으로 유연성이 높습니다. 비용은 응답자의 50%로 3위를 차지했습니다.
확장성 때문에 사람들은 퍼블릭 클라우드를 선호하고, 장기적으로는 비용 때문에 다시 프라이빗 클라우드를 선호하는 것으로 나타났습니다.
현실적으로 대부분의 조직은 '퍼블릭 클라우드'를 제공하는 곳도 아니고 '프라이빗 클라우드만 제공하는 곳'도 아닙니다. 앱을 앞뒤로 옮긴 후에도 멀티 클라우드가 유지됩니다. 현실은 Cap Gemini가 "클라우드 네이티브의 시대가 온다" 보고서에서 보고한 개발 동향을 살펴보면 입증할 수 있습니다. 이 보고서는 "응답자 회사의 신규 애플리케이션 중 6분의 1(15%)이 오늘날 클라우드 네이티브 환경에서 구축되고 있다"고 언급했습니다.
이제, 만약 15%가 클라우드 네이티브라면, 나머지 85%는 클라우드 네이티브가 아니라는 뜻입니다. 여기에는 메인프레임도 포함될 겁니다. 그리고 클라이언트-서버. 3단계 웹앱입니다. 아, 컨테이너화된 환경에서의 마이크로서비스도 있죠.
현대의 기업 조직은 멀티 클라우드일 뿐만 아니라 애플리케이션 아키텍처 측면에서도 여러 세대에 걸쳐 있습니다.
즉, 온프레미스(비공개)에서 오프프레미스(공개)로 또는 그 반대로 앱을 마이그레이션할 가능성이 매우 높습니다. 클라우드 기반 앱보다 온프레미스 앱의 수가 더 많기 때문입니다. 그러므로 중요한 것은 그 전제를 클라우드 전략에 통합하는 것입니다. 다시 말해, (어쩌면 불가피한) 과정을 덜 고통스럽게 만들기 위해 미리 무엇을 할 수 있는지 이해해야 합니다.
가장 먼저 고려해야 할 사항 중 하나는 옮기려는 앱의 예상 수명입니다. 장기적으로 보면 향후 클라우드 간 마이그레이션의 후보가 될 수 있습니다. 그렇지 않은 경우(홍보, 마케팅 또는 이벤트 기반인 경우) 이 목록의 끝으로 바로 건너뛰어 배포할 수 있습니다.
이제 앱의 수명이 길어질 것이라고 판단했다면 앱을 확장하고 보안을 강화할 방법을 생각해야 합니다.
보안 비누 상자 사이드바 앱이 입력이나 터치 데이터를 수락하지 않더라도 여전히 보안 이 필요합니다. 앱 보안은 스택이며, 둘 다 보호하지 않으면 손상될 수 있는 플랫폼과 프로토콜이 있습니다. 메타데이터 조작 공격(HTTP 헤더를 대상으로 하는 공격)은 사용자 지정 코드로 인한 취약성만큼(어쩌면 그보다 더) 위험합니다. 모든 앱은 보안 측면에서 중요합니다. |
앱이 클라우드 네이티브라면 빠르고 쉬운 대답은 "클라우드 공급업체의 서비스를 사용하겠습니다"입니다. 이는 유효한 옵션입니다. 앱이 온프레미스 프라이빗 클라우드에서 실행될 경우 "항상 사용해 온 것을 사용하겠습니다"가 유효한 옵션인 것과 마찬가지입니다. 그러나 두 옵션 모두 서비스 및/또는 정책을 한 클라우드에서 다른 클라우드로 원활하게 마이그레이션할 수 없다는 다운스트림의 잠재적 위험이 따릅니다. 지금 사용하고 있는 확장성과 보안을 면밀히 살펴보고 해당 애플리케이션 서비스가 앱과 함께 양방향으로 마이그레이션될 수 있는지 확인해야 할 때입니다.
기업이 앱을 제공하고 보호하기 위해 평균 16개의 애플리케이션 서비스를 사용한다는 점을 감안하면, 이는 멀티 클라우드 환경에서 앱을 지원하는 것은 물론이고 마이그레이션될 수 있는 앱을 지원하는 능력을 심각하게 방해할 수 있는 영역입니다. 16개 서비스 중 일부 는 클라우드 기반 서비스여야 합니다. 기본적으로 데이터 경로를 기업용, 공유 애플리케이션 서비스, 앱별 서비스로 구성된 것으로 본다면 아키텍처 구분이 퍼블릭 클라우드 공급업체가 인프라 계층에서 그은 선과 매우 일치한다는 것을 알 수 있습니다. 완벽한 구분은 아니지만 어떤 서비스가 "멀티 클라우드"가 되어야 하고 어떤 서비스가 클라우드 네이티브 또는 기존 데이터 센터 서비스에 의존할 수 있는지에 대한 지침을 제공하는 논리적 구분을 제공합니다.
클라우드 전반에 걸쳐 사용하는 애플리케이션 서비스의 일관성이 높을수록 두 클라우드(또는 세 클라우드, 네 클라우드 이상) 간 마이그레이션이 쉬워집니다. 왜냐하면 구속력이 덜하기 때문입니다. 이러한 접근 방식은 자동화 노력을 퍼블릭 클라우드까지 확장하고, 최소한 별도의 운영 인력과 절차를 유지하는 데 따른 운영 비용을 기업에서 덜어준다는 추가 이점이 있습니다.
클라우드는 불가피했습니다. 멀티 클라우드도 마찬가지입니다. 결국 이는 그들 사이에 이주가 일어날 것이라는 것을 의미합니다. 앱을 배포할 위치를 처음 결정하기 전에 종속성에 주의를 기울이고 크로스 클라우드 애플리케이션 서비스를 활용하면 프로세스가 덜 번거로울 수 있습니다.
최소한 클라우드 간 마이그레이션 아이디어를 최상위 클라우드 전략의 일부로 삼으세요. 미리 준비해 두면 나중에 고통스럽고 비용이 많이 드는 이전 과정을 예방할 수 있습니다.