기업에 트윈이 필요한 이유, 그리고 Mithril이 그것을 제공하는 방식

프로덕션은, 누가 민감한 시스템에 도달할 수 있는지, 거부가 어떤 모습인지, 실행 중인 클러스터가 선언된 것과 같은지를 알아볼 곳이 아니다. 트윈은 그 이름들을 유지하고 결과를 적용하지 않는다. Mithril은 그 트윈을 문서로 만든다. 역도메인 컴포넌트는 조합되고, 한 번의 실행은 응답과 판정을 돌려주며, 클러스터는 기동되지 않은 채 관측과 대조된다.

이 글은 기계 번역입니다.

기업에 트윈이 필요한 이유는, 중요한 질문을 프로덕션에서 물을 수 없기 때문이다. 고객 데이터를 보유한 시스템에 누가 도달할 수 있는가. 할당량이 소진되었을 때 거부된 호출은 어떤 모습인가. 오늘 실행 중인 클러스터가 선언된 클러스터인가. 프로덕션은 고객과 결제와 신원이 이미 살고 있는 곳이다. 그곳을 답을 배우는 장소로 쓰면, 호기심이 장애와 묶인다. 위원회가 확신할 때까지 모든 변경을 멈추는 것은 또 다른 실패이다. 자산 체계는 계속 움직이고, 그 모형은 따라가지 못한다.

트윈은 같은 이름을 가진 그 자산 체계의 두 번째 사본이며, 아무것도 적용되지 않는다는 단단한 규칙을 가진다. 주체, 버킷, 큐, 클러스터는 질문에 답할 만큼은 실재한다. 효과는 사본에서 멈춘다. 보안, 플랫폼, 아키텍처는 허용, 거부, 장애, 드리프트를, 그 가운데 어느 것도 고객에게 청구하는 계정에 닿기 전에 예행할 수 있다.

Mithril은 트윈을 두 번째 클라우드가 아니라 문서로 만든다. 자산 체계의 각 부분은 역도메인으로 이름 붙인 컴포넌트이고, 컴포넌트는 조합된다. 신원, 인가, 할당량, 일관성, 장애, TLS는 그것들을 필요로 하는 서비스 아래에 놓인다. 한 번의 실행은 그 사슬을 따라가며, 호출자가 가져갈 수 있는 2가지를 돌려준다. 클라이언트가 보게 될 응답과, 그 응답을 만들어 낸 판정이다. applied 플래그는 false인 채로 남는다. 런타임은 소켓을 열지 않으며, 실가동 호스트나 비밀을 지목하는 문서는 실행 전에 거부된다.

같은 경계가 클러스터에도 덮인다. Docker와 Podman은, 어떤 서비스가 존재해야 하고 서로 어떻게 의존하는지를 적은 Mithril 문서로 감싸진다. 그 문서를 렌더링하면 Compose 파일이 나온다. 점검은 선언을 실제로 관측된 것과 비교한다. 점검은 컨테이너를 시작하지 않는다. 기업이 얻는 것은 자사 자산 체계의 예행이며, 이미 클라우드 프로토콜을 말하는 엔진들 옆에 두고, 무엇이 결정되었고 무엇이 의도적으로 적용되지 않았는지의 기록이 남는다.