성공적인 클라우드 마이그레이션: 도약하기

여러분은 아마 모르고 계실지 모르겠지만, 오늘날 우리가 알고 있는 클라우드는 2006년 8월 당시 구글 CEO였던 에릭 슈미트에 의해 처음 정의 되었습니다. 솔직히 말해서, 아무도 이 아이디어를 진지하게 받아들이지 않았습니다(적어도 실질적인 측면에서는). 훨씬 나중까지 말입니다.

단 5년 만에 클라우드가 중요해졌고 기존 애플리케이션을 클라우드 플랫폼으로 옮기는 것이 의미하는 바에 대한 많은 고민이 이루어졌습니다. 사실, 플랫폼 이전에 관해 이전에 얻은 교훈 중 많은 부분이 오늘날에도 여전히 적용됩니다.

제가 이 포럼에서 이전에도 공유했듯이, 아무것도 쉬운 일은 없습니다. 클라우드로 도약하기로 결정했다면 진짜 작업이 시작되는 것입니다.

성공적인 이주 노력을 위해서는 이주를 지원하는 포괄적인 전략을 개발하는 것뿐 아니라, 사전에 어려운 결정을 내리는 것도 필요합니다. 가장 유혹적인 결정은 이 단계를 모두 건너뛰고 바로 마이그레이션 활동에 뛰어드는 것입니다. 하지만 그 "쉬운" 결정은 클라우드 이전을 실패로 이끌 수 있습니다.

모범 사례 모델을 도입한 IT 전문가는 원하는 결과를 이해하고 여정에서 성공을 검증하고 측정하는 메커니즘을 갖추는 것부터 시작합니다. 이 시점부터 어떤 애플리케이션을 마이그레이션할지에 대한 적절한 평가와 마이그레이션 목표(예: 향상된 성능, 감소된 지연 시간, 확장성)에 대한 이해가 이루어질 수 있습니다.

1단계 – 정말 이걸 하고 싶은가요?

과장된 광고와 낮은 비용 모델에 대한 약속에도 불구하고, 모든 기업이나 모든 애플리케이션이 클라우드 프레임워크로 전환해야 하는 것은 아닙니다. 오해하지 마세요. 많은 앱이 클라우드 배포에 적합하며 어떤 앱은 다른 앱보다 이동하기 쉽지만 비즈니스에 미치는 영향을 신중하게 고려해야 합니다. 너무나 자주, 저는 임원이 IT 부서에 "클라우드로 이동"하라고 명령하는 공포스러운 이야기를 들었습니다. 하지만 그 의미가 무엇인지 제대로 이해하지 못한 채 말입니다. 그리고 여러분도 저와 같다면, 제대로 이해하는 것보다 더 좋은 것은 없습니다. 더 나은 접근 방식은 전반적인 전략에서 설정한 목표와 관련하여 실제적인 사업 사례를 개발하는 것입니다. "내가 왜 이 일을 하고 있는가?"라는 질문에 답하세요. 솔직히 말해서, 비용 절감의 매력만이 고려되는 기준이라면 실수를 범하고 있는 것일 수 있습니다.

2단계 – 무엇을 옮겨야 할까요? 그리고 왜 옮겨야 할까요?

전문가마다 이 단계를 부르는 명칭이 다르지만, 실제로는 기존 환경을 점검하는 단계입니다. 예를 들어, 온프레미스 환경에서 VMware 프레임워크에서 애플리케이션을 실행하는 이점이 있고 추가적인 확장성을 원한다면 방금 발표된 F5/VMware/IBM Cloud 결합 상품을 활용하는 것이 적합할 수 있습니다. F5의 BIG-IP 가상 서비스 제품군 뿐만 아니라 VMware 솔루션 포트폴리오를 위한 IBM Cloud와의 자동 프로비저닝 및 통합을 활용하는 검증된 솔루션을 제공함으로써 클라우드로의 전환을 훨씬 더 쉽게 만들 수 있습니다.

이 솔루션을 활용하면 다음과 같은 이점을 얻을 수 있습니다.

• 다운타임 감소를 위한 확장 가능한 애플리케이션 제공
• F5 프로그래밍 기능에 대한 기존 투자를 활용하여 출시 시간을 단축합니다.
• 빠른 작업 부하 배포에 대한 장애물 제거
• 온프레미스와 IBM Cloud 간 워크로드 이동성 제공
• 원활한 애플리케이션 장애 조치로 가동 중지 시간 제거
• F5의 엔터프라이즈급 성능, 가용성 및 보안 서비스의 일관된 적용

다른 프레임워크 내에서 운영하는 경우 기본 지원 시설(예: 컴퓨팅, 스토리지, 인프라)과 소프트웨어 라이선싱과 관련된 제한 사항을 신중하게 고려하세요.

이 단계에서는 애플리케이션 자체(실행하는 데 필요한 것뿐 아니라)에 대해서도 깊이 생각하는 것이 중요합니다. 몇 년 전에 개발된 애플리케이션을 옮기는 게 합리적일 수 있지만, 10년 동안 사용되어 온 애플리케이션을 옮기려고 시도하는 건 그다지 합리적이지 않을 것입니다. 기술 부채의 부담을 결코 잊지 마십시오. 요즘은 너무 많이 쓰이는 용어이긴 하지만 진짜 과제는 정상적으로 실행하는 데 필요한 도메인별 지식이고, 새로운 영역에서는 더더욱 그렇습니다. CTR/IBM의 토마스 왓슨이 1911년에 말했듯이, "생각하세요!" 그러면 괜찮을 겁니다.

3단계 - "난 해낼 거야!!!"

설계. 설계. 설계. 이주하다. 검증합니다. 반복하다. 이 간단한 조언을 따르면 성공 가능성이 높아집니다. 오늘날 많은 기업이 클라우드 출시를 위해 CI/CD(지속적인 개선, 지속적인 배포) 전략을 채택했습니다.

대부분의 노력은 비교적 간단한 성격의 애플리케이션부터 시작하여 거기에서 배웁니다. 저 역시 이 접근 방식이 제 팀 내에서 사용할 때에도 가장 효과적이라고 생각합니다. 반복적인 프로세스는 제품과 서비스 모두에서 빠르고 지속적인 개선으로 이어집니다. 이 경우 클라우드에서 애플리케이션이 성공합니다. 그리고 첫 번째 움직임에서 어느 정도 성공하고 나면 배우면서 점점 더 쉬워질 겁니다.

물론, 새로 배포된 애플리케이션을 테스트하고 모든 것이 제대로 실행되고 우주가 끝나지 않았는지 확인한 후 레거시 시스템을 종료하기 위한 전략을 수립했는지 확인하세요.

이 단계에 대한 마지막 조언은... 개인적으로 가장 좋고(가장 성공적인) 배포는 애플리케이션 개발 팀과 네트워크 운영 팀이 잘 일치하고 전체 프로세스 동안 함께 작업하는 배포라는 것을 발견했습니다.

4단계 – 현대적이고 클라우드 지향적인 관행 채택

클라우드 여정의 첫 단계이자, 폐기한 레거시 시스템에서 첫 번째 애플리케이션을 마이그레이션할 때, 현대 IT는 작업 수준의 참여가 아닌 시스템 수준의 사고방식에 관한 것이라는 점을 명심하세요. 이 되다 버튼을 누르는 사람이 아니라 버튼을 만드는 사람입니다.

다음 게시물에서는 실제 이주 옵션에 대한 좀 더 구체적인 아이디어를 제공해 드리겠습니다. 계속 지켜봐 주세요.