다음을 통해 공유


가드레일을 사용하여 셀프 서비스를 통해 개발자의 역량 강화

가드레일을 사용한 셀프 서비스는 개발 팀이 잘 정의된 매개 변수 또는 가드레일 집합 내에서 자체 결정을 내릴 수 있도록 하는 원칙입니다. 가드레일은 주요 이해 관계자가 설립하고 동의합니다. 관련자는 조직 전체의 보안, 운영, 아키텍처 팀을 포함할 수 있습니다.

가드레일을 사용한 셀프 서비스를 통해 개발 팀은 독립적으로 개발 결정을 내릴 수 있는 자율성을 유지합니다. 자동화 및 정책은 관련자가 보안, 규정 준수, 운영, 표준 및 비용을 적절하게 관리하도록 도와줍니다. 이 자동화를 사용하도록 설정하려면 개발자, 운영자 및 전문가가 필요한 거버넌스를 희생하지 않고도 더 많은 작업을 수행할 수 있도록 팀 라인 간에 협업이 필요합니다. 그런 다음 개발자는 비즈니스 가치를 최대한 빨리 제공하는 데 집중할 수 있습니다.

[개발자에게 알려주세요.] 모든 작동 방식에 대해 걱정하지 말고, 켜거나 끄고, 채우고, 무엇을 해야 하는지에 문자열을 넣고, 기본적으로 추가 정보 파일이 있고 입력, 출력을 가지고 있으며 원하는 대로 넣을 수 있는 점에서 셀프 서비스입니다. - Daniel, Cloud Engineer, Fortune 500 Media Company

포장된 경로에 셀프 서비스 환경을 제공하는 목표는 개발 팀, 운영 및 관리에 대한 가시성을 제공하면서 개발자의 수고를 줄이는 것입니다. 기본 자동화 및 데이터 집계 기능 덕분에 학습 곡선이 최소화된 지정된 작업에 대한 환경을 만들 수 있습니다. 인프라 프로비전과 같은 활동 외에도 이러한 환경은 관찰 가능성, 정책, 인시던트 관리 등에 중요한 기능에 대한 액세스를 제공할 수 있습니다. 이 아이디어는 공유 도구 및 서비스와 함께 내부 API, SDK의 검색 및 공유로 확장됩니다. 이러한 환경은 오버헤드를 줄여 개발 팀이 작업을 수행하는 데 집중할 수 있도록 합니다.

내부 개발자 플랫폼은 개발자가 디지털 상점 고객처럼 작동할 수 있도록 합니다.

내부 개발자 플랫폼은 비즈니스 간 디지털 상점과 유사한 기능을 제공합니다. 디지털 매장은 기본적으로 고객이 셀프 서비스를 제공하도록 설계되었습니다. 다른 사람과 대화하지 않고도 흥미로운 항목을 검색하고 이행할 수 있는 방법을 제공하기 때문에 기존 매장 앞보다 더 많은 처리량을 처리할 수 있습니다. 이 비유를 사용하여 개발자는 고객이며 내부 개발자 플랫폼은 유사한 셀프 서비스 환경을 제공합니다. 소매업체, 운영자, 플랫폼 엔지니어 및 기타 역할과 마찬가지로 개발자가 조직의 가드레일을 수용하도록 설계된 항목 카탈로그를 설정할 수 있습니다.

예를 들어 새 도구에 대한 액세스를 요청하는 개발자가 디지털 상점 주문을 하는 것처럼 생각할 수 있습니다. 주문과 마찬가지로 요청이 제출되면 개발자는 진행 상황을 추적하고 완료 시기를 알 수 있기를 원합니다. 백그라운드에서 요청은 필요에 맞게 올바른 처리 공급자로 자동으로 라우팅되어야 합니다. CI/CD(연속 통합 및 배달) 시스템 중 하나를 하나의 처리 공급자, GitOps 도구 또는 규범적인 애플리케이션 플랫폼을 초로, 수동 프로세스를 위한 워크플로 자동화 도구를 3분의 1로 생각할 수 있습니다. 모든 경우에 개발자는 잘 정의된 카탈로그의 항목을 동일한 방식으로 셀프 서비스할 수 있습니다.

모든 항목을 코드 패턴으로 사용

CD(지속적인 업데이트) 파이프라인 및 GitOps 도구를 통해 IaC(인프라를 코드)로 사용하는 것은 셀프 서비스를 사용하도록 설정하는 데 중요한 부분입니다. CD를 사용하는 IaC를 사용하면 Bicep, Terraform, Helm 차트 및 기타 도구를 사용하여 요청 시 클라우드 리소스를 만들고 삭제할 수 있습니다. 클라우드 인프라의 구성은 소스 코드 리포지토리의 코드와 마찬가지로 관리되므로 보안 및 감사 기능과 같은 git 리포지토리의 모든 이점을 적용할 수 있습니다.

일반적인 인프라 및 도구를 프로비전하는 것이 IaC 접근 방식의 유일한 장점은 아닙니다. Azure Policy 및 Open Policy 에이전트와 같은 도구를 통해 코드로 보안 및 정책을 코드로 포함하여 다른 시나리오에 대한 코드 패턴으로 조정할 수 있습니다. 이 기술에 따라 구성 파일(일반적으로 YAML 또는 JSON)이 리포지토리로 푸시되고, 이때 파일을 처리하는 워크플로가 트리거됩니다. 이러한 파일은 dependabot.yml 또는 CODEOWNERS와 같은 앱 리포지토리이거나 별도의 중앙 리포지토리에서 유지 관리될 수 있습니다. 이를 사용자 고유의 시나리오로 확장하여 EaC(코드)로 모든 것을 현실로 만들 수도 있습니다.

개발자는 셀프 서비스 환경을 구동하고 기본적으로 모범 사례를 권장하는 중앙 카탈로그를 사용하여 이러한 각 EaC 템플릿을 참조할 수 있습니다.

올바른 템플릿 시작 만들기 및 올바른 거버넌스 유지 설정

소프트웨어 개발에서는 애플리케이션을 디자인할 때 캡슐화, 모듈성 및 구성성을 목표로 합니다. 템플릿을 통해 플랫폼 엔지니어링에 이와 동일한 사고 라인을 적용해야 합니다. 예를 들어 중앙에서 보호되고 재사용 가능한 IaC 템플릿 집합을 만들어 인프라의 구성 요소로 사용할 수 있습니다.

[개발자]를 위한 모듈을 빌드합니다... 따라서 백 엔드 자체를 작성하거나 걱정할 필요 없이 애플리케이션 코드에 대해 걱정하기만 하면 됩니다. - Daniel, Cloud Engineer, Fortune 500 Media Company

IaC, EaC 및 애플리케이션 템플릿을 소스 코드 리포지토리 만들기, 샘플 코드 시드 또는 권장 관찰 도구에 대한 구성 및 샘플 코드 제공과 같은 다른 작업으로 확장되는 맞춤형 EaC(코드) 솔루션으로 결합합니다. 그런 다음 이러한 IaC, EaC 및 애플리케이션 템플릿을 리포지토리, ADE(Azure Deployment Environments)의 카탈로그 또는 클라우드 네이티브용 ACR(Azure Container Registry)과 같은 중앙 보안 위치에서 저장하거나 참조할 수 있습니다.

시작 오른쪽 템플릿이 자동화된 거버넌스, 검사 및 정책 구성과 결합되면 개발자는 첫날부터 바로 유지됩니다.

플랫폼 엔지니어링 그래픽이 제대로 시작되고 올바른 템플릿 개요를 유지합니다.

템플릿은 자동화된 보안 사례를 사용하여 개발을 간소화합니다.

애플리케이션 템플릿을 사용하여 개발자가 프로젝트 과정을 수행하는 몇 가지 주요 결정 및 작업에 대해 정의된 포장된 경로를 부트스트랩합니다. 올바른 템플릿을 시작하고, 필요한 도구에 대한 액세스를 제공하는 자동화를 사용하도록 설정하고, CI/CD 파이프라인을 구성하고, 인프라 및 애플리케이션 스택을 프로비전하고, 필요한 SDK 또는 API에 대한 참조를 포함하는 보일러 플레이트 소스 코드가 포함된 리포지토리를 구성하여 개발자가 안전하고 관리되는 개발 사례를 수립하고 신속하게 시작할 수 있습니다.

이러한 애플리케이션 템플릿이 다른 중앙 집중식 템플릿(예: IaC 템플릿)을 참조하게 함으로써 이러한 각 개별 구성 요소는 자체의 시작 올바른 템플릿이 됩니다. 이러한 템플릿은 출력을 정의할 뿐만 아니라 개발자가 선택할 수 있는 옵션도 제공하므로 셀프 서비스 환경을 사용하도록 설정하는 데 핵심적인 요소입니다.

템플릿은 거버넌스, 보안 및 비용 최적화를 보장합니다.

그러나 템플릿은 단순히 개발 작업을 부트스트래핑하는 것 이상의 작업을 수행해야 합니다. 또한 프로젝트 수명 주기 동안 올바르게 유지하는 데 필요한 정책 및 보안 검사를 통해 제어 및 거버넌스를 설정해야 합니다. 또 다른 예로 템플릿은 프로덕션으로 무단 병합을 방지하는 분기 보호 규칙을 설정할 수 있습니다. 템플릿은 모범 사례 및 일반적인 구성을 캡처하기 때문에 도구, 공급업체 및 팀 간에 비용을 최적화하기 위한 주요 기술 중 하나입니다.

올바른 캠페인 실행으로 양방향 통신 빌드

마지막으로, 포장된 경로에 대한 신뢰도가 높아짐에 따라 애플리케이션 템플릿에 어셈블한 기본 개별 구성 요소를 사용하여 기존 애플리케이션을 포장된 경로로 이동할 수 있습니다. 내부 고객에게 파일럿된 포장 경로의 값이 이미 표시되므로 내부 get right 캠페인을 실행하여 다른 애플리케이션 팀과 양방향 대화 상자를 만들 수 있습니다. 개발자는 애플리케이션을 마이그레이션하는 방법을 배울 수 있으며, 플랫폼 엔지니어링 팀은 동시에 해당 애플리케이션을 위한 플랫폼을 개선하는 방법에 대해 자세히 알아봅니다.

자신만의 여정 차트

셀프 서비스 기능이 포함할 수 있는 다양한 환경을 고려할 때, 내부 개발자 플랫폼이 증분 방식으로 가치를 제공할 수 있도록 투자 노력과 계획 및 우선 순위 지정 에 중요한 초점을 맞춥니다. 내부 개발자 플랫폼을 만드는 각 조직의 여정은 서로 다르며 제품 사고 방식을 따르면 셀프 서비스 환경이 필요한 가장 중요한 위치를 먼저 대상으로 지정할 수 있습니다.