Cloud Native Maturity Model

안녕하세요, 베스핀글로벌 DevOps실 홍완승 님이 작성해 주신 Cloud Native Maturity Model에 대해 알아보겠습니다.

대상

이 모델의 주요 대상은 광범위하며 다음 그룹을 포함합니다.

디지털 트랜스포메이션의 길을 시작하거나 시작하는 기업

클라우드 네이티브 기술로의 전환을 시작하고자 하는 기술자는 앞으로의 여정을 더 자세히 이해하고 더 많은 조사 영역을 강조하고자 합니다

모델을 분할하는 방법

클라우드 네이티브 성숙도를 개발하는 것은 단순한 기술 여정이 아니라 다음 네 가지 주요 영역의 영향을 받는 여정입니다.

  • 사람 – 우리는 어떻게 일하고, 어떤 기술이 필요하며, 이 프로세스를 진행하면서 조직은 어떤 모습이며, 사람들이 일하는 방식에 보안을 어떻게 엮습니까?
  • 프로세스 – 어떤 프로세스가 필요한지, 어떤 기술이 필요한지, IaC(Infrastructure as Code)를 사용하여 워크플로와 CI/CD를 매핑하는 방법, 보안을 가능한 한 “맨 왼쪽”으로 이동하는 방법은 무엇입니까?
  • 정책 – 보안 및 규정 준수 의무를 달성하는 데 필요한 내부 및 외부 정책은 무엇입니까? 이러한 정책이 귀사의 비즈니스 운영 환경을 반영합니까?
  • 기술 – 클라우드 네이티브의 이점을 제공하고 사람, 프로세스 및 정책뿐만 아니라 CI/CD 기술, GitOps 채택, 가시성, 보안, 스토리지, 네트워킹 등을 지원하는 데 필요한 기술입니다.
  • 비즈니스 결과 – 비즈니스는 클라우드 네이티브에서 무엇을 달성할 것으로 기대할 수 있습니까? CXO 및/또는 비즈니스 리더십에 이점을 어떻게 전달할 예정입니까?
이 모델이 맞지 않는 경우 

이 모델의 목표는 지나치게 규범적인 것이 아니라 여정을 안내하는 데 도움이 되는 도구가 되는 것입니다. 클라우드 네이티브 변환은 정확한 과학이 아니라 프로젝트, 조직 내에서 발생하며 물론 특정 시간과 장소에서 발생합니다.

클라우드 네이티브 성숙도 모델에 대한 필수 구성 요소

클라우드 네이티브를 채택할 때 해야 할 첫 번째이자 틀림없이 가장 중요한 일은 비즈니스 및 기술 목표, 특히 비즈니스가 연습을 통해 얻을 것으로 기대하는 것을 간략하게 설명하는 것입니다.

완전히 백지 상태(종종 그린필드라고도 함)로 시작하는 조직은 거의 없습니다. 다음과 같은 문제가 있을 수 있습니다.

조직의 연령은 몇 개월, 몇 년, 수십 년 또는 그 이상일 수 있습니다. 그리고 기술 부채를 징수할 수 있습니다.

상당한 응용 프로그램, 플랫폼 및 인프라 자산이 있을 수 있습니다.

클라우드 서비스 공급자로의 마이그레이션을 시작했을 수도 있으며, 기존 자산에 대해 ‘리프트 앤 시프트’ 접근 방식을 채택했을 수도 있습니다.

당신이 가져야 할 가장 중요한 것은 당신이 달성하고자 하는 비즈니스 결과에 대한 명확한 아이디어입니다. 이것들은 당신의 의사 결정 과정을 안내하는 데 도움이 되는 ‘북극성’이 될 것입니다.

적절한 시기는 언제인가

다음 조건을 충족하는 경우 클라우드 네이티브 여정을 시작할 준비가 된 것입니다.

사람
  • 개발과 운영 사이에는 상당한 분리가 있으며, 인프라, 클라우드, 애플리케이션 운영 및 개발 간의 명확한 직원 설명이 있습니다.
  • 기존에는 운영 및 인프라 부서와 애플리케이션 개발 부서를 분할했습니다. 이는 규정 요구 사항에 의해 시행되었을 수 있습니다.
프로세스
  • 응용 프로그램 배포는 대부분의 경우 수동으로 수행될 수도 있고, 릴리스 프로세스를 완료하는 데 시간이 오래 걸릴 수도 있으며, 여러 번 시도하는 경우가 많습니다.
  • 동일한 소프트웨어의 여러 배포를 지원할 수 있으며 상당한 가동 중지 시간 없이 업그레이드하거나 평가하는 데 문제가 있을 수 있습니다.
정책
  • 정책은 응용 프로그램 및 해당 플랫폼 외부에 있는 규칙 및 규칙의 양식일 수 있으며 응용 프로그램 및 런타임 환경 내에서 기본적으로 적용되지 않습니다.
  • 정책은 이질적이고 사일로에 구축될 수 있습니다. 심층 패리티의 방어는 고의적이라기보다 사고에 가까울 수 있습니다.
기술
  • 주문형 VM이 있을 수 있습니다.
  • 일부 자동화가 흩어져 있습니다.
  • SIEM, RBAC 개념 및 일부 유형의 디렉터리와 같은 기본 보안 구성 요소가 있습니다.
  • 일부 소프트웨어 패키징이 있지만 일관성이 없을 수 있습니다.
  • 경계 보안과 레이어 1-4에서 일부 코스 네트워크 영역 지정이 있을 수 있지만 약간의 불안과 보안 관행을 느낄 수 있습니다.
  • 암호화에 대한 경험은 다를 수 있습니다 – 예를 들어 일부 인증 기관이 있을 수 있지만 많은 사람들에게 진입 장벽이 높아 광범위하게 사용되지 않을 수 있습니다.
  • 응용 프로그램은 고가용성을 위해 인프라 솔루션에 의존할 수 있으며, 이는 결국 원하는 것보다 더 많은 비용이 들 수 있습니다
  • 서버 자산은 가용성이 낮은 단일 물리적 또는 가상 서버에서 고가용성 클러스터에 이르기까지 다양할 수 있습니다. 확장은 진정한 도전이 될 수 있으며 비용, 시간 및 계획에 상당한 투자가 필요할 수 있습니다.
  • ‘Everything as Code’ 모델에 발을 담그기 시작했을 수 있습니다. 즉, Terraform으로 인프라를 스크립팅하기 시작했습니다.
비즈니스 성과
  • 비즈니스는 성장하고 있으며 수요를 충족하기 위해 확장할 수 있는 능력이 필요합니다.
  • 비즈니스는 탁월한 고객 경험을 개선 및/또는 제공해야 합니다.
  • 비즈니스는 기능을 더 빨리 출시해야 합니다.
  • 클라우드 네이티브 성숙도 모델 여정The Cloud Native Maturity Model Journey

클라우드 네이티브 성숙도 모델에는 5단계가 있습니다. 

한 응용 프로그램의 경우 5단계에 있을 수 있지만 동시에 다른 응용 프로그램의 경우 2단계에 있을 수 있습니다. 성숙 단계를 식별할 때 이를 염두에 두십시오.

클라우드 네이티브 성숙도 모델 5단계

수준 1: 빌드

기본 클라우드 네이티브 구현이 준비되어 있고 사전 프로덕션 단계에 있습니다.

수준 2: 운영

클라우드 네이티브 기반이 설정되고 프로덕션으로 이동합니다.

레벨 3: 규모 역량이 커지고 있으며 규모

를 위한 프로세스를 정의하고 있습니다.

수준 4: 개선

환경 전반에서 보안, 정책 및 거버넌스를 개선하고 있습니다.

수준 5: 최적화 이전에 내린 결정을 재검토하고 최적화

를 위해 애플리케이션과 인프라를 모니터링합니다.

출처 :

감사합니다 🙂

Written by 홍 완승 / Tom Hong

Cloud Engineer

Leave a Comment