각 고객은 중요합니다.
플랫폼 엔지니어링의 한 가지 주요 원칙은 고객을 위해 최적화하는 것입니다. 개발자를 기본 고객으로 생각하고, 포장하려는 개발 경로를 결정할 때 먼저 해당 요구 사항에 집중합니다. 개발자는 모두 다른 도구를 사용하여 작업을 완료합니다. 첫 번째 단계로, 새로운 내부 개발자 플랫폼을 구현하기 전에 작게 시작하고 기존 화면과 표면을 개선할 수 있는지 여부를 평가합니다.
고객 중심 내부 플랫폼을 사용하여 개발자의 역량 강화
개발자를 내부 개발자 플랫폼의 기본 고객으로 생각하는 것은 성공에 필수적입니다. 이러한 고객은 개발자라고 하지만, 팀 토폴로지 모델이 스트림 정렬 팀으로 지칭하는 모든 구성원이 될 수 있습니다. 여기에는 기계 학습 전문가 또는 데이터 과학자와 같은 역할이 포함됩니다.
성공적인 플랫폼 엔지니어링 사례는 개발자와 운영자에게 권한을 부여합니다. 개발자와 운영자는 기존의 표준, 거버넌스 및 보안 규칙을 준수하면서 비즈니스 가치를 제공하는 의사 결정을 내릴 수 있는 자율성을 갖습니다. 특정 하위 시스템(운영, 보안, 규정 준수 및 아키텍처)에서 팀과 전문가를 지원하는 중요한 이해 관계자는 이 내부 플랫폼을 빌드하는 팀과 협력하여 전문 지식과 모범 사례를 템플릿 및 시스템 기능으로 명문화합니다. 이 지식을 시스템으로 동시에 이동하면 개발자의 인지 부하가 감소하고, 보안, 규정 준수 및 품질이 향상되며, 이러한 다른 역할의 크기를 개선하여 진정으로 고유한 문제를 해결할 수 있습니다. 그러나 플랫폼이 관련된 모든 사람에게 가장 많은 혜택을 반환하도록 하는 것은 개발자 환경입니다.
즉, 플랫폼 엔지니어링 활동을 계획하고 우선 순위를 지정하는 고객 중심 접근 방식을 따르는 것을 의미합니다.
모범 사례를 간소화하기 위한 최적의 개발 경로 식별
조직에는 현재 프로덕션에 대한 다양한 개발 경로가 있을 수 있지만 플랫폼 엔지니어링 과정의 초기 단계는 개발자가 사용할 경로를 이해하는 것입니다. 이 호출을 수행하면 개발, 운영 및 거버넌스 요구 사항을 충족하는 효율적인 경로를 포장하는 데 에너지를 집중할 수 있기 때문에 중요합니다.
이러한 포장된 경로는 개발, 운영 및 기타 이해 관계자가 모범 사례를 나타내는 데 동의하는 내용에 맞게 형성된 특정 개발 및 관찰 도구, 언어, SDK 및 서비스 집합을 나타냅니다. 포장된 경로에는 내부 재사용을 위한 온보딩, 조정 및 옹호를 간소화하는 방법이 포함되어야 합니다. 이러한 포장된 경로를 제한적이거나 강제적인 경로로 생각할 필요가 없으며 개발자의 수고를 개발 팀이 해당 경로 내에 유지하려는 지점으로 줄일 필요가 없습니다.
그러나 어떤 경로에 집중할지, 경로의 어느 부분을 먼저 포장해야 하는지를 이해하는 것이 중요합니다.
사용자가 있는 위치의 사용자 만나기
내부 개발자 플랫폼의 모든 항목에 대한 통합 포털로 시작하는 것이 좋지만 이것이 가장 좋은 시작점은 아닙니다.
운영 전문가, SRE(사이트 안정성 엔지니어) 및 개발자는 모두 다양한 도구를 사용하여 작업을 완료합니다. 코딩은 IDE에서 발생하고, GitHub 및 Azure DevOps와 같은 엔지니어링 시스템은 명령줄 인터페이스를 사용하며, 실시간 공동 작업은 Teams 및 Slack에서 수행됩니다. 종종 이러한 사용자는 이러한 화면에 만족하고 걱정할 또 다른 사용자 인터페이스를 경계합니다.
소규모로 시작하여 새 사용자 지정 환경 빌드를 시작하기 전에 기존 화면 및 표면, 빌드 플러그 인 또는 확장을 개선할 수 있는지 여부를 평가합니다. 다른 새로운 사용자 환경이나 개선된 버전의 사용자에 대해 사람들이 더 잘 반응할 수 있을까요? 처음부터 처음부터 포털을 빌드하기로 결정한 경우 API를 통해 둘 이상의 인터페이스를 지원할 수 있다는 생각을 고려합니다. 또한 낮은 코드 프레임워크를 사용하는 것과 같은 옵션의 잠금을 해제하므로 포털 환경을 처음부터 빌드하고 호스트할 필요가 없습니다.