1. 클라우드 선정 절차
○ 서비스 재고 (1) : 서비스 유형
▷ 현재 기업 아키텍처의 필요사항을 충족시키기 위해 사용자가 선택할 수 있는 클라우드 컴퓨팅 유형 또는 카테고리는 수없이 존재한다.
▷ 따라서, 필요한 서비스 유형을 선택하여야 한다.
▷ 서비스 유형은 (3~6강 내용 복습)
- SaaS(Software-as-a-Service: 서비스 형태로 제공되는 보안 기능),
- TaaS(Testing-as-a-Service: 서비스 형태로 제공되는 테스트 기능)
- PaaS(Platform-as-a-Service: 서비스 형태로 제공되는 플랫폼)
- IaaS(Infrastructure-as-a-Service: 서비스 형태로 제공되는 인프라)
-위의 모두 서비스의 종류에 관계없이 모두 각자의 상충요소(Tradeoffs)가 있고, 각자가 해결하려는 문제 영역이 있다. 어쨌든 사용자는 자신의 아키텍처를 판단 기준으로 삼아야 한다.
○ 서비스 재고 (2): 클라우드 서비스 카테고리
※ 다양한 클라우드 서비스 카테고리는 아래와 같이 분류된다.
 |
- 스토리지
- 데이터베이스
- 정보
- 프로세스
- 애플리케이션
- 플랫폼
- 통합
- 보안
- 관리/거버넌스(Governance)
- 테스팅, 그리고
- 인프라스트럭처
|
○ 서비스 재고 (3) : 서비스의 재 분류
※ 소분류
▷ 솔루션
- 공급업체별로 정도로 특정 문제들만을 해결해주는 서비스
▷ 서비스는
- 스토리지, 데이터베이스, 정보, 프로세스, 통합, 보안, 관리/거버넌스, 그리고 테스팅 서비스
※ 대분류
▷ 솔류션
- 공급업체별로 독자적으로도 완벽한 플랫폼을 제공하는 서비스
▷ 서비스는
- 애플리케이션, 플랫폼 그리고 인프라 서비스
- 하나의 대분류 클라우드 컴퓨팅 서비스 업체가 여러 개의 소분류 자원으로 구성될 수 있음
○ 서비스 재고 (4) : 서비스 분류별 구성요소
▷ 프로세스의 경우,
- 서비스 구성요소: 애플리케이션, 플랫폼, 인프라, 프로세스, 통합
▷ 데이터의 경우,
- 서비스 구성요소는 애플리케이션, 플랫폼, 인프라, 스토리지, DB, 정보
▷ 서비스의 경우,
- 서비스 구성요소: 애플리케이션, 플랫폼, 인프라, 그리고 정보
▷ 서비스 업체가 제공하는 것을 한 예의 가상 구조적 분류를 기준의 한예
- 프로세스 : Appian Anywhere를 통한 프로세스 서비스.
- 데이터 : 아마존 EC2(Elastic Computing Cloud)를 통한 인프라 서비스와 아마존 Simple DB를 통한 데이터베이스 서비스.
- 서비스 : 아마존 EC2를 통한 인프라 서비스
· 사용자는 데이터를 아마존 EC2 플랫폼뿐 아니라 아마존 Simple DB에 저장할 수도 있다.
· 그 다음, 사용자는 가령, 해당 플랫폼 내에서 온디맨드(On-Demand) 방식으로 제공되는 애플리케이션(application) 서버를 이용해 아마존 EC2 플랫폼 상에서 서비스를 구축 및 호스팅할 수 있다.
· 끝으로, 사용자는 이런 프로세스들이 운용될 플랫폼으로 Appian Anywhere를 사용할 수 도 있다.
· 프로세스가 서비스와 연결되고, 서비스는 데이터에 연결된다는 점을 명심하라. 사용자는 여기서 단지 대상 플랫폼을 선정할 뿐이다.
▷ 예를 들면, 하나의 PaaS(Platform-as-a-Service) 공급업체가
- 스토리지, 데이터베이스, 프로세스, 보안 그리고 테스팅 서비스를 한꺼번에 제공할 수도 있다.
- 여러 개의 소분류 자원을 제공하는 하나의 대분류 클라우드 컴퓨팅을 사용하는 것이 더 편할 수도 있겠지만, 판단은 전적으로 사용자 아키텍처의 요구사항 몫이다.
▷ 요구사항 및 자체 아키텍처와의 완벽한 연결을 고려했을 때, 여러 개의 소분류 클라우드 솔루션을 선택하는 것이 사용자의 아키텍처와 더 잘 어울린다고 판단할 수도 있다.
▷ 그러므로 클라우드 컴퓨팅 서비스 업체 카테고리 후보를 다음과 같은 아키텍처상의 구성요소를 기준으로 생각하는 것이 도움이 된다.
▷ 더 많은 클라우드 컴퓨팅 공급업체가 관련된 좀 더 복잡한 예를 살펴보자.
- 프로세스 : Appian Anywhere를 통한 프로세스 서비스와 세일즈포스닷컴을 통한 애플리케이션 서비스
- 데이터 : 3Tera Cloudware와 아마존 EC2를 통한 인프라 서비스 그리고 아마존 Simple DB를 통한 데이터베이스 서비스
- 서비스 : 아마존 EC2, 3Tera Cloudware를 통한 인프라 서비스와 세일즈닷컴을 통한 애플리케이션 서비스, 그리고 세일즈포스닷컴의 포스닷컴
(Force.com)을 통한 플랫폼 서비스
▷ 혹은, 다음과 같이 단일 클라우드 컴퓨팅 공급업체를 통해 간단한 방식을 택할 수도 있다.
- 프로세스 : 아마존 EC2를 통한 프로세스 서비스
- 데이터 : 아마존 EC2를 통한 인프라 서비스
- 서비스 : 아마존 EC2를 통한 인프라 서비스
▷ 이뿐만 아니라, 사용자는 자신의 필요에 따라 구내 또는 클라우드에 설치할 수 있는 보안, 테스팅, 그리고 거버넌스 등 다른 핵심 아키텍처 구성요소도 고려할 필요가 있다.
▷ 이렇게 설명하는 이유는 사용자가 가지고 있는 구조적 선택사항에 대해 설명하고 아키텍처, 최종적으로는 기업의 요구조건 충족을 위해 필요한 만큼의 선택사항을 이용하여 최종 아키텍처를 형성하기 위해 선택사항들을 어떻게 조합할 수 있는지를 보여주기 위함이다.
2. 클라우드 이전 과정
○ 다음 페이지의 그림은 보여준 매핑 과정 후에, 사용자가 올바른 클라우드 컴퓨팅 카테고리, 그리고 마침내는 적합한 클라우드 컴퓨팅 서비스 업체를 찾아내 자신의 프로세스, 서비스, 그리고 데이터를 좋은 클라우드 컴퓨팅 후보로 선정된 서비스 업체로 이전할 때 활용할 수 있는 전체 과정을 나타낸 것이다.
○ 핵심 단계는 다음과 같다.
① 후보 플랫폼 목록 작성
② 후보 플랫폼 분석과 시험
③ 타깃 플랫폼 선정
④ 타깃 플랫폼 설치
○ 아래의 그림은 프로세스의 각 단계와 프로세스, 서비스 그리고 데이터들에 대한 요구조건을 파악하고,그 요구조건들을 적합한 기술에 매핑 과정을 도시하고 있다.
1)1단계 : 후보 플랫폼 목록 작성
▷ 사용자는 자신의 ”미래”아키텍처에 적합할 것으로 보이는 클라우드 컴퓨팅 플랫폼 목록을 일부 또는 전체 작성할 필요가 있다. 이를 위해서는 어떤 플랫폼들이 있는지, 어떤 카테고리에 속해 있는지 그리고 어떤 기능을 하는지 사용자가 정확하게 이해하고 있어야만 한다.
▷ 클라우드 컴퓨팅 솔루션이 어떠해야 하는지를 정의하는 확고 부동한 규칙은 존재하지 않는다. 그러므로 많은 소프트웨어 공급업체들이 자신들의 솔루션이 진정한 클라우드 컴퓨팅 솔루션이든 아니든, 클라우드 솔루션을 가지고 있다고 말하는 경향이 있다.
▷ 예를 들면, 일부 소프트웨어 공급업체들은 자사의 소프트웨어가 웹을 통해서 구내 컴퓨팅 시스템으로 다운로드 될 수 있으므로 자신들이 On-Demand 방식 또는 클라우드 컴퓨팅 플랫폼이라고 주장하고 있다. 사실은 그렇지 않다. 결국, 이 단계는 단지 목록을 주고받는 게 아니라 옥석을 구분하는 과정이다.
▷ 클라우드 컴퓨팅에 통달하기 위해서는 각 공급업체들이 제공하는 게 무엇인지를 이해하고 있어야 하므로 시장 상황이 어떻게 돌아가고 있는지를 꿰뚫고 있어야 한다. 그러므로 다음 두 가지 질문에 답을 할 수 있어야 한다.
① 필요한 것이 어떤 카테고리인가?
② 그 카테고리에 속해 있는 클라우드 컴퓨팅 공급업체
▷ 누구를 목록에 포함시킬 것인가? 채택할 카테고리는 최종 논리 아키텍처와 이 프로세스 동안 밝혀낸 요구사항에 의해 결정된다.
| 1 단계에서 몇 가지 일반적인 사항들 고려해야 한다. 즉 반드시 필요한 기본적인 계층과 각 계층에서 확인해야 할 사항이 있다(<그림> 참조). 기본적인 계층으로는 스토리지, 데이터베이스, 프로세스, 서비스, 보안, 거버넌스 그리고 관리 계층 등이 있다. 아래의 그림은 핵심 아키텍처에서 요구되는 스토리지, 데이터, 애플리케이션, 거버넌스, 보안, 서비스 그리고 프로세스들의 연관 관계를 보여 주고 있다. |
○ 스토리지 (Storage)
▷ 아키텍처의 일부 또는 전체를 지원하는 파일 시스템의 저장, 공유, 그리고 관리를 가능케 해주는 클라우드 서비스이다.
▷ 이를 위해서는 흔히 스토리지 서비스만 제공하는 클라우드 컴퓨팅 서비스 업체나 IssS의 일부로 스토리지 서비스를 제공하는 공급업체의 SaaS를 사용한다.
▷ 여기서 확인해야 할 사항은 용량(Capacity)과 성능이다.
- 용량은 아키텍처 지원을 위해 필요에 따라 스토리지를 확장할 수 있게 해주는 기능이다.
- 성능은 기업의 원활한 운영에 도움이 되는 속도로 클라우드 컴퓨팅 서비스와 파일을 교환하는 기능을 말한다.
▷ 여기서, 성능 문제가 가장 중요한 문제이므로 반드시 테스트를 해야 한다.
○ 데이터베이스 (DataBase)
▷ 이는 플랫폼, DB 또는 인프라 서비스를 이용한 데이터의 저장과 검색 기능이다.
▷ 여기서 고려할 사항으로는 클라우드를 통해 전달되는 DB에서 사용자의 아키텍처가 필요로 하는 특성과 기능이 포함되어 있는 지이다.
- 다시 말해 내장 함수(Stored Procedures)와 트리거(Triggers), API 함수, 표준 함수, 그리고 성능 등을 확인해야 한다.
▷ IaaS에 국한해서 보면, 클라우드 컴퓨팅 서비스 업체들은 대개 오라클이나 MySQL 같은 잘 알려진 DB 만 제공한다.
- DaaS(Database-as-a-Service) 공급업체들은 대개 자체 개발한 데이터베이스를 사용하므로 업체 고유의 DB 인 경우가 많다.
▷ 여기서도 성능이 한 몫을 한다.
- 구내에 설치된 기존 애플리케이션은 대개 데이터 입출력 집중형이므로, 여기서도 유사한 성능 문제가 존재함을 알게 될 것이다.
- 여러 사용자가 공유하는 플랫폼의 입출력 오버헤드(Overhead)와 인터넷을 통해 다량의 데이터를 클라우드 컴퓨팅 업체와 기업이 교환할 때 발생할 수 있는 지연시간(Latency)를 고려해야 한다.
▷ 이 때문에 데이터베이스 DB 를 사용하는 프로세스와 서비스 가까이에 데이터베이스를 두기로 결정할 수도 있다.
- 이는 데이터베이스의 성능과 신뢰성을 고려한 아키텍처의 핵심 원칙이다
○ 프로세스 (Process)
▷ 대부분의 경우, 프로세스, 플랫폼, 애플리케이션, 그리고 인프라 공급업체들 상에 존재할 수 있다.
▷ 고려할 사항은 프로세스 공급업체가 제공하는 프로세스뿐이다.
- 사용자가 다른 구조적 구성요소(대개는 서비스와 데이터)를 프로세스에 묶어 주어야 한다.
- 데이터와 서비스는 시스템 내부 혹은 다른 클라우드 컴퓨팅 공급업체에 있으므로 통합 작업이 이루어지고 있는 지를 확인해야 한다.
- 프로세스의 신뢰성 확인도 역시 사용자의 몫이다.
▷ SaaS 경우
- 공급업체들은 대개 사용자가 자신의 프로세스를 생성할 수 있는 플랫폼을 제공하지는 않지만, 자신들의 플랫폼에서 사전에 구축된 프로세스를 사용하는 것은 허용한다. 왜냐하면, 공급업체가 제공하는 사전에 구축된 프로세스를 사용하면되므로 사용자가 맞춤형 주문처리 프로세스를 만들 필요가 없기 때문이다.
▷ IaaS와 PaaS(Platform-as-a-Service) 경우
- 대개의 경우 스토리지, 데이터베이스, 프로세스, 애플리케이션 서비스, 개발, 그리고 테스팅이 포함된 “완벽한 스택”을 제공하는 플랫폼을 다루고 있음을 의미한다. 프로세스들은 그런 플랫폼들의 한 구성요소일 뿐이다.
· “완벽한 스택”공급업체들은 클라우드 컴퓨팅의 원스톱 쇼핑이므로, 이런 공급업체를 이용하고 싶은 생각도 들것이다. 어떤 PaaS 공급업체의 애플리케이션 개발 기능은 엄청 마음에 드는데, 제품을 관리하는 방식이나 제공하는 프로세스 엔진은 전혀 마음에 들지 않는 경우에는 절충을 해야만 할 것이다. 많은 경우, 간편성이 희생되더라도 기업의 아키텍처에 적합한 프로세스를 활용하기 위해서는 해당 프로세스를 처리하기 위해 다른 클라우드 컴퓨팅 공급업체나 심지어는 구내 소프트웨어를 이용하는 것이 더 낫다.
○ 서비스 (Service)
▷ 일반적으로 말해서, 웹 서비스 같은 서비스는 대부분의 클라우드 컴퓨팅 플랫폼에 존재 할 수 있다.
▷ 하지만, 소수의 클라우드 컴퓨팅 공급업체들(플랫폼, 프로세스, 그리고 인프라 서비스공급업체)만이 서비스를 생성해서 호스팅 할 수 있는 능력을 제공한다.
▷ 반면, 애플리케이션, 정보 서비스 공급업체들은 자신들이 호스팅 하는 사전 구축된 서비스에 대한 액세스는 허용하지만, 서비스 수정은 불가능하다.
▷ 가장 일반적인 문제는 성능이다.
▷ 웹 서비스 같은 서비스들은 (REST나 SOAP사용에 관계없이) 서비스를 호스팅하는 플랫폼이서비스에 컴퓨팅 자원을 충분히 제공하지 못하거나 플랫폼과 네트워크를 포화상태로 만들 정도로 서비스가 너무 많을 경우에 성능 문제를 일으키는 경향이 있다.
▷ 실제로 서비스를 사용하여 플랫폼을 테스트하고 나서 플랫폼, 사용하는 서비스 개수, 아키텍처의 성능을 최적화하기 위해 서비스를 설계한 방식 등을 조정해야 한다.
○ 보안 (Security)
▷ 필요한 요구조건을 기반으로 아키텍처를 보호하기 위한 전략과 모델을 만들어 보안을 처리해야 한다.
▷ 보안은 구내 또는 클라우드 컴퓨팅 플랫폼상에 존재하는 플랫폼도 아니고 소프트웨어도 아니다. 제대로만 구현하면, 구내든 아니면 클라우드 컴퓨팅을 통해서건 보안 기능이 제공되는 위치와 역할 분담에 상관없이 아키텍처의 구조적 속성(Systematic Attribute)이 될 것이다.
▷ 적절한 접근방식과 요소 기술을 선택한다.
- 이런 노력이 ID 관리와 ID 관리를 지원하는 표준을 중심으로 이루어지고 있다.
- SOA(Service-oriented Architecture)와 클라우드 컴퓨팅을 이용한 SOA 같은 더 복잡하고 분산된 아키텍처를 지원하는 차원에서 ID 관리에 대한 관심이 높아지면서, 이 영역을 더 잘 정의하기 위한 표준의 필요성이 대두되고 있다.
▷ 왜 ID 관리가 필요한가?
▷ 이런 표준들은 모든 조직의 ID 관리 시스템을 통합된 하나로 함께 묶어 모든 사용자들이 안전하게 알 수 있도록 하는 것을 목표로 하고 있다.
▷ 클라우드 컴퓨팅을 사용하는 순간부터 서비스들을 내부에서만 사용하던 시절은 막을 내린다.
▷ 서비스를 사용하는 사람(소비자)이나 서비스를 만드는 사람(공급자)이 서로 상대방을 알지 못하면 악의적인 행동이나 부정확한 행동을 감수해야 한다.
▷ 그 결과 대단히 비싼 대가를 치르게 될 수도 있다.
▷ 클라우드 컴퓨팅에서는 이것이 현실이다.
○ 거버넌스 (Gorvernace):
▷ 거버넌스 시스템은
- 클라우드 컴퓨팅의 각종 정책을 구현, 관리, 집행한다.
- 속성상 런타임(Runtime)이며, 대개는 구내에 존재한다.
▷ 중요한 요소는 성능이다.
- 어떤 때는 정책을 집행하면 시간지연 문제가 발생하는 경우가 있다.
- 이에 대한 성능 저하 요소가 있는 지를 판단해야 한다.
- 또 다른 요소는 능력이다.
- 클라우드를 통해 전달되는 서비스에 해당하는 자원들을 관리하기 위한 거버넌스 메커니즘의 능력이다.
- 거버넌스 기술이 리포지토리(Repository) 내에서 원격 서비스를 추적할 수 있는 능력과 실행 중에 해당 서비스들을 감시할 수 있는 능력을 가지고 있는지를 의미한다.
○ 관리 (Management)
▷ 관리 기술
- 클라우드 컴퓨팅을 이용한 서비스 구조는 분산되어 있는 경우가 많고, 복잡한 구조이다. 이러한 클라우드 컴퓨팅 구조를 총괄하는 기술이다.
▷ 클라우드 도입 시에 관리 기술 확인
- 클라우드 공급업체의 관리기술이 대화형 인터페이스를 가지고 있는 지를 확인해야 한다.
- 핵심은 “동작을 하는지 하지 않는지를 알 수 있는 수준”에서 구내 시스템과 클라우드 컴퓨팅 기반 시스템을 모두를 볼 수 있는 관리 시스템을 제공하는 지를 검토 해야 한다.
- 이를 바탕으로, 최소한 시스템이 다운되었는지, 그 상태가 다른 시스템에는 어떻게 영향을 주고 있는지를 파악 할 수 있다.
▷ 좀 더 섬세한 수준, 즉 서비스, 프로세스, 데이터, 스토리지 별로 시스템을 볼 수 있는 관리 시스템을 확보하여 문제를 진단하고, 실제로 문제가 발생하기 전에 이를 감지할 수 있는 시스템을 갖는 것이 바람직하다.
▷ 관리와 거버넌스는 밀접하게 연계되어 있으며, 매우 유사한 패턴을 갖는다.
○ 2단계 : 후보 플랫폼 분석과 시험 (Test) -1
▷ 사전에 설정한 요구조건을 충족시키는지 분석 및 확인
- 이 작업은 선정한 각 후보 플랫폼을 심층적으로 분석한 다음, 시험을 통해 수행한다.
▷ 클라우드 시험
- 실제로는 클라우드 컴퓨팅 플랫폼의 포괄적인 능력을 시험한다는 점에서 구내 시험과 약간 다르다.
- 좀 더 구체적으로 말하면, 구성요소들을 실제로 플랫폼 상에 설치하기 전에 해당 클라우드 플랫폼이 서비스, 데이터, 그리고 프로세스를 포함한 구조적 구성요소의 요구조건을 어떻게 수용하는지 검토하게 될 것이다.
▷ 성능 모델링 (Modeling)
▷ 모델링은 서로 다른 유형의 부하 상태에서 시스템이 어떻게 동작해야 하는지에 대한 시뮬레이션을 만들어 낸다. 대개 경량, 중급, 대량으로 구분한다.
- 어떻게 정보가 흐르고 어떤 서비스가 호출되는지, 그리고 그런 사항들이 구내와 클라우드 기반 컴퓨팅 자원들에게는 어떤 영향을 주는 지 등 아키텍처를 모델링하는 것을 의미한다.
○ 2단계 : 후보 플랫폼 분석과 시험 (Test) - 2
▷ 성능 시험 (Testing)
- 성능 실험이란 부하가 걸렸을 때 아키텍처가 어떤 성능을 제공하는 지를 결정하기 위해 테스팅을 진행한다는 것을 의미한다.
- 클라우드 컴퓨팅에서 어느 정도의 성능을 기대할 수 있는지, 그리고 처리 능력 감소와 대역폭 확장 같은 상황들이 전체 성능에는 어떤 영향을 주는지 등에 대해 감은 잡을 수 있다. 성능 모델을 입증하는 동안에는 성능 테스팅을 사용해야 한다.
▷ 본 후보 프랫폼의 분석과 시험 의미
- 클라우드 기반의 전체 아키텍처가 얼마나 잘, 그리고 얼마나 빨리 업무를 지원하는지를 평가하는 것이다.
- 더 나가서, 끊임없이 증가하는 스토리지, 데이터베이스, 프로세스, 그리고 서비스 처리 부하 상태에서 시스템이 어떤 성능을 제공하는지도 측정해야 한다.
- 이러한 과정을 통해서 네트워크, 데이터베이스, 그리고 서비스 같은 잠재적 병목 구간을 찾아서 이를 수용하거나, 대안을 찾거나 아니면 포기하고 다른 업체를 찾을 수도 있다.
○ 3단계 : Target 플랫폼 선정
▷ 클라우드 컴퓨팅 플랫폼을 선정
- 일단 이 모든 분석과정과 보안과 거버넌스를 감안한 다음에 후보 시스템 목록을 종합해서 검증 시험을 완료된 후에 클라우드 컴퓨팅 플랫폼을 선정한다.
- 요구조건 충족을 하였는가?
▷ 클라우드 컴퓨팅 공급업체가 어떠한 상태인가?
- 공급업체의 생존력과 사용자의 클라우드 컴퓨팅 플랫폼을 지속적으로 지원할 가능성
- 하드웨어, 소프트웨어, 그리고 네트워크 장애로부터 복구하는 능력
- SLA(Service Level Agreement와 사용자의 아키텍처를 위해 어느 정도의 서비스 레벨이 지원되어야 하는 지에 대한 클라우드 공급업체와 사용자 간의 공감대
- 클라우드 컴퓨팅 공급업체의 정책과 어떤 것이 위반 사항인지에 대한 완벽한 이해
○ 4단계 : Target 플랫폼 설치
▷ 실행단계
- 사용자가 실제로 코드를 포팅하고, 데이터를 이전하며, 새로운 서비스, 프로세스 그리고 데이터베이스를 생성하며, 이 모든 서비스, 데이터베이스, 그리고 프로세스가 제대로 동작하는지를 테스트하고 검증하는 단계이다.
- 이전과 개발을 중심으로 하는 접근방식을 택해야 한다.
- 가장 중요한 것부터 시작해서 중요도가 가장 낮은 것의 순서로 아키텍처 중의 어떤 구성요소를 이동시키거나 클라우드 컴퓨팅 플랫폼에서 생성해야 할지를 결정해야 한다.
▷ 아키텍처의 구성요소를 클라우드 컴퓨팅 플랫폼으로 이동시킬 때, 제대로 기능하는 지를 확인하고 다음 구성요소로 넘어가기 전에 적절하게 테스트되었는지도 확인한다.
▷ 점진적인 접근방식이 문제도 없고 클라우드 컴퓨팅 플랫폼에 서비스, 데이터, 그리고 프로세스를 설치하는 사람들이 일에 치이지 않게 해 준다.
▷ 이런 접근방식은 일을 해나가면서 배울 수 있는 학습 효과도 제공하므로 프로세스가 진행됨에 따라 클라우드 컴퓨팅 플랫폼을 사용자의 아키텍처에 맞게 작동시키는 방법에 대한 지식도 크게 증진될 것이다.
○ 최종 단계 : 새로운 클라우드 컴퓨팅 플랫폼 수용
▷ 실행 및 운영 단계
- 실제로 시스템을 클라우드로 옮겨서 그 시스템들을 업무에 맞게 동작시키는 작업이다.
- 기획이나 분석보다는 실행 작업이지만, 관련된 작업 중 가장 까다로운 작업이 기도 하므로 위험부담도 가장 크다.
▷ 클라우드 컴퓨팅은 아직도 변화하고 있는 중이기 때문에 광고와 시장이 뜨거워짐에 따라 매주 새로운 공급업체가 등장하고, 기존 공급업체들은 시장을 장악하기 위해 더 많은 기능성을 추가하기에 여념이 없다.
▷ 클라우드 컴퓨팅 플랫폼은 지속적으로 수행해야 하는 작업이다. 즉 정기적인 업그레이드, 버그 수정, 그리고 플랫폼에 대한 다른 변경사항의 원인이 되는 소프트웨어 배포가 필요하다.
▷ 이런 변경사항들이 전체 시스템을 더 나은 방향으로 유도하고 이런 플랫폼 상에 존재하는 아키텍처 상의 구성요소를 훼손하는 일은 없어야 한다.
