2017.09.13

IDG 블로그 | 클라우드로 워크로드를 옮기는 데 걸리는 시간

David Linthicum | InfoWorld
필자가 항상 받는 질문 중 하나이다. 일정한 수의 애플리케이션을 클라우드로 옮기는 데 시간이 얼마나 걸리는가? 물론 여기에는 표준적인 컨설턴트의 대답이 있다. “경우에 따라 다르다.”

하지만 마이그레이션에 얼마나 많은 작업이 들어갈지 일반적 이해를 얻는 데 적용할 수 있는 몇 가지 대원칙이 있다. 이들 대원칙은 기능과 목적, 복잡성, 데이터 연결, 클라우드 네이티브 기능 사용 여부 등을 다룬다.



많은 기업이 애플리케이션을 수정없이 마이그레이션했으면 한다. 즉 리프트 앤 시프트 방식을 선호한다. 이 방식은 ID 관리나 자산 관리, 거버넌스와 같은 클라우드 네이티브 기능의 이점을 얻지 못하지만, 속도를 위해서 클라우드 네이티브 기능을 기꺼이 희생할 수 있는 경우도 있다.

만약 이 방향으로 나간다면 2~3명의 개발자와 DBA가 코드와 데이터를 이식하는 데 2~3일이 걸린다. 여기에 100을 곱하고 시간이 지나면서 빨라지는 속도를 빼면, 약 200일이면 100개의 워크로드를 퍼블릭 클라우드로 이전할 수 있다. 일주일 정도의 시간은 차이가 날 수 있다.

하지만 만약 애플리케이션을 클라우드에 맞도록 리팩터링하겠다고 결정한다면, 계산이 완전히 달라진다. 이때는 애플리케이션의 얼마나 많은 부분을 리팩터링해야 하는지, 그리고 그 작업의 복잡성도 고려해야 한다.

대원칙의 하나로, 애플리케이션의 리팩터링 비율이 높아지면 그만큼 시간도 더 많이 걸린다. 필자는 10%에 1주일 정도를 잡는데, 이렇게 계산하면 애플리케이션의 30%를 클라우드 네이티브하게 리팩터링한다면, 퍼블릭 클라우드로 옮기는 데 3주가 걸리는 것이다. 워크로드 100개에 적용하면, 300주가 걸린다.

물론 이 시간은 어디까지나 3명의 개발자와 DBA를 기준으로 한 것이므로, 더 많은 자원을 추가해 병렬로 작업을 진행하면 기간을 훨씬 단축할 수 있다. 단지 비용이 더 많이 들고 위험성도 높아질 뿐이다.

그리고 그외에도 많은 것을 잊어버리지 말아야 한다. 애플리케이션 설계, 데이터베이스 연동, 데이터베이스의 종류 등 목록은 끝없이 길어진다.

이들 질문은 해답을 필요로 하지만, 우리는 문제를 해결하는 “인상적인 한 마디”를 좋아하는 세상에 살고 있다. 정확한 측정값을 얻을 수 있는 위치에 있다면, 이런 대원칙이 예산 관련 질문에 일반화된 “인상적인 한 마디” 답변을 제공할 수 있을 것이다. 기억해야 할 것은 “악마는 디테일에 있다”는 것이다.  editor@itworld.co.kr

2017.09.13

IDG 블로그 | 클라우드로 워크로드를 옮기는 데 걸리는 시간

David Linthicum | InfoWorld
필자가 항상 받는 질문 중 하나이다. 일정한 수의 애플리케이션을 클라우드로 옮기는 데 시간이 얼마나 걸리는가? 물론 여기에는 표준적인 컨설턴트의 대답이 있다. “경우에 따라 다르다.”

하지만 마이그레이션에 얼마나 많은 작업이 들어갈지 일반적 이해를 얻는 데 적용할 수 있는 몇 가지 대원칙이 있다. 이들 대원칙은 기능과 목적, 복잡성, 데이터 연결, 클라우드 네이티브 기능 사용 여부 등을 다룬다.



많은 기업이 애플리케이션을 수정없이 마이그레이션했으면 한다. 즉 리프트 앤 시프트 방식을 선호한다. 이 방식은 ID 관리나 자산 관리, 거버넌스와 같은 클라우드 네이티브 기능의 이점을 얻지 못하지만, 속도를 위해서 클라우드 네이티브 기능을 기꺼이 희생할 수 있는 경우도 있다.

만약 이 방향으로 나간다면 2~3명의 개발자와 DBA가 코드와 데이터를 이식하는 데 2~3일이 걸린다. 여기에 100을 곱하고 시간이 지나면서 빨라지는 속도를 빼면, 약 200일이면 100개의 워크로드를 퍼블릭 클라우드로 이전할 수 있다. 일주일 정도의 시간은 차이가 날 수 있다.

하지만 만약 애플리케이션을 클라우드에 맞도록 리팩터링하겠다고 결정한다면, 계산이 완전히 달라진다. 이때는 애플리케이션의 얼마나 많은 부분을 리팩터링해야 하는지, 그리고 그 작업의 복잡성도 고려해야 한다.

대원칙의 하나로, 애플리케이션의 리팩터링 비율이 높아지면 그만큼 시간도 더 많이 걸린다. 필자는 10%에 1주일 정도를 잡는데, 이렇게 계산하면 애플리케이션의 30%를 클라우드 네이티브하게 리팩터링한다면, 퍼블릭 클라우드로 옮기는 데 3주가 걸리는 것이다. 워크로드 100개에 적용하면, 300주가 걸린다.

물론 이 시간은 어디까지나 3명의 개발자와 DBA를 기준으로 한 것이므로, 더 많은 자원을 추가해 병렬로 작업을 진행하면 기간을 훨씬 단축할 수 있다. 단지 비용이 더 많이 들고 위험성도 높아질 뿐이다.

그리고 그외에도 많은 것을 잊어버리지 말아야 한다. 애플리케이션 설계, 데이터베이스 연동, 데이터베이스의 종류 등 목록은 끝없이 길어진다.

이들 질문은 해답을 필요로 하지만, 우리는 문제를 해결하는 “인상적인 한 마디”를 좋아하는 세상에 살고 있다. 정확한 측정값을 얻을 수 있는 위치에 있다면, 이런 대원칙이 예산 관련 질문에 일반화된 “인상적인 한 마디” 답변을 제공할 수 있을 것이다. 기억해야 할 것은 “악마는 디테일에 있다”는 것이다.  editor@itworld.co.kr

X