프로토타입 이후에 필요한 인프라 정의하기

생성된 시스템부터 살펴보세요

가상의 프로토타입 플랫폼을 생각해 보세요. 웹 컨테이너, 관리형 PostgreSQL 데이터베이스, 공개 URL을 만듭니다. 예시 레코드로 작업 흐름이 정상 작동합니다. 유용한 결과입니다. 더 큰 구현에 자금을 투입하기 전에 사람들이 기능을 평가할 수 있습니다.

이제 회사가 기밀 계약을 저장하고 직원 ID 제공자를 사용하려 합니다. 필요한 시스템이 바뀌었습니다. 컨테이너 배포의 성공만으로 인가, 승인된 데이터 처리, 복구 가능성, 서비스 책임이 확립되지는 않습니다.

개발 플랫폼마다 제공하는 기능이 다릅니다. 실제 서비스와 구성을 살펴보세요. 모든 프로토타입 도구의 한계가 같거나 익숙한 클라우드 이름이면 회사 정책을 충족한다고 가정하지 마세요.

기존 엔터프라이즈 서비스를 활용해 답할 수 있습니다. 애플리케이션마다 새 ID 시스템이나 모니터링 플랫폼을 만들 필요는 없습니다. 승인된 기능에 연결하고 남는 공백을 기록하세요.

AWS Well-Architected는 운영, 보안, 신뢰성, 성능, 비용, 지속 가능성을 함께 고려합니다. 정상 작동하는 배포는 아키텍처 평가의 일부라는 점을 상기시켜 줍니다. 프레임워크 읽기.

개발, 테스트, 프로덕션 리소스를 식별하세요. 어떤 ID가 이 경계를 넘을 수 있는지 정하세요. 승인된 처리 절차 없이 편리한 미리보기 환경에 프로덕션 레코드를 복사하지 마세요.

들어오는 접근뿐 아니라 외부로 나가는 연결도 살펴보세요. 비공개 데이터베이스도 애플리케이션을 통해 공개 로깅 서비스로 데이터를 보낼 수 있습니다. 코딩 에이전트의 모델 호출도 별도로 평가해야 할 흐름입니다.

클라우드 계정, DNS, 인증서, 암호화 키, 청구 관계의 소유자를 기록하세요. 떠나는 직원의 개인 계정에 의존하는 프로젝트는 애플리케이션 코드가 있어도 소유권 문제가 있습니다.

관리형 데이터베이스 제공자가 기반 서비스를 운영하는 동안 조직은 사용자, 데이터 접근, 스키마 변경, 보존 설정을 통제할 수 있습니다. 정확한 분담은 서비스와 계약에 따라 달라집니다. 명시적으로 확인하세요.

계약 애플리케이션에 대해 가상의 복원 훈련을 수행하세요. 실제 복구 시간을 측정하고 발생 가능한 데이터 손실을 확인하세요. 결과를 비즈니스 요구사항과 비교하세요. ‘백업 활성화’ 체크박스는 같은 증거가 아닙니다.

접근 권한 회수도 테스트하세요. ID 원천에서 가상의 직원을 제거하고 의도한 접근 변경이 이루어졌는지 검증하세요. 활성 세션, 관리자 역할, 자동화 ID도 설계에 포함하세요.

인프라 정의, 환경 구성, 파이프라인, 애플리케이션 코드는 조율된 변경이 필요합니다. 에이전트는 실제 대상 환경을 기준으로 계획해야 합니다. 그렇지 않으면 네트워크, ID, 소유권 요구사항과 충돌하는 배포를 생성할 수 있습니다.

이 지점에서 플랫폼 엔지니어링과 소프트웨어 팩터리가 만납니다. 플랫폼은 지원 기능과 경계를 제공합니다. 소프트웨어 제공 시스템은 이를 사용하고 증거를 만들며 명확한 운영 인계를 유지해야 합니다. 플랫폼 엔지니어링에서 계속 학습하세요.