Platform Engineering Study

플랫폼은 파운데이션.

각 애플리케이션 팀들은 플랫폼을 사용해서, 팀간 조정 비용을 줄여야하고, 더 빠른 속도로 제품의 기능들을 딜리버리 가능해야함.

플랫폼 엔지니어링은, 플랫폼을 개발하고 운영하는 하나의 분야.

• 비즈니스 레버리지를 전달하기 위해, 전체 시스템의 복잡성 관리.

레버리지

• 소수의 플랫폼팀 엔지니어들의 작업이 조직 전체의 업무를 줄여줘야함.
• 애플리케이션 엔지니어들이 비즈니스 가치를 창출하는 과정에서 생산성을 높여야하고,
• 애플리케이션 엔지니어링 팀 간의 중복작업을 제거하여 엔지니어링 조직의 효율을 높여야함.

제품

• 플랫폼을 하나의 제품으로서 봐야한다.
• 제품에 반영할 것들을 잘 큐레이션하고, 반영하지 않을 것들을 신중하고 세련되게 큐레이션해야함.

과도한 일반화의 늪.

• 소프트웨어의 생애주기비용 중 최소 60~75%가 초기 개발이후에 발생.
  • 그중 1/4은 마이그레이션 같은 적응적 유지보수에 사용.
• 접착제 (glue)
  • 통합 코드, 일회성 자동화, 구성, 관리도구 등.
  • 모든것을 하나로 묶어주지만, 동시에 미래의 변경을 매우 어렵게 만드는 끈적임의 원인.
  • 모노레포의 툴킷 패키지레이어.
  • 시간이 지나면서, 이 끈적이는 혼란을 변경하기 대단히 어려워짐.
  • 접착제가 도처에 퍼져있으면, 기본요소들의 사소한 업데이트도 통합과 테스트를 위한 광범위한 조직차원의 엔지니어링 시간을 필요로 함.
  • 따라서, 접착제의 양을 제한하는 것이 중요.
    • 상자는 늘리되, 연결선은 줄인다.
  • OSS 와 벤더의 선택을 조직의 필요에 맞게 제한된 집합으로 추상화하고, 강력한 의견을 제공하여 관심사의 분리가 되어야함.
• 추상화와 캡슐화의 개념을 구현하고, 사용자를 바탕(underlying) 복잡성으로부터 보호하는 인터페이스를 구축해서 필요한 접착제의 양을 제한한다.
  • 추상화의 진짜 가치는 바탕(underlying) 기술을 교체할 때 드러남. ex. stackflow 를 다른 라우팅으로 대체할 때.

간접비용을 최소화하면서 기본요소 제한하기.

• 플랫폼 엔지니어링은 광범위한 요구사항을 충족할 수 있는 소수의 기본요소를 큐레이션하는 고객 중심의 제품 접근 방식을 취해야한다.
  • 비즈니스 현실을 고려한 타협과, 좋은 플랫폼 아키텍쳐의 증분 전달 필요.
  • 애플리케이션 팀과 직접 협력하여 그들의 요구사항을 경청하려는 자세가 필요.
    • 하지만, how 는 플랫폼에서 결정하기.
• 하지만, 소수의 기본 요소를 선정하는것은 좋으나, 언제 기본요소로 승격시킬지가 더 어려움.
  • 너무 일찍 추상화하면 유즈케이스를 충분히 이해하지 못한 채 인터페이스가 굳어버림 (premature abstraction).
  • 너무 늦으면 이미 앱마다 각자의 glue가 퍼져서 통합 비용이 커짐.

애플리케이션별 접착제 줄이기.

• 사용중인 기본요소의 수를 줄이는 것에서, 한걸음 더 나아가 남은 요소들과의 접착제를 줄이는것을 목표로한다.

마이그레이션 비용의 중앙화.

• 애플리케이션과 기본요소들의 수명은 길다. 그리고 그 수명들은 각각 독립적이다.
• 긴 수명동안 이들은 많은 변화를 겪는다.
• 그러한 변화들이 모여 높은 유지보수 비용이 발생한다.

애플리케이션 개발자의 자체 운영권한.

• 바탕 시스템의 운영 복잡성을 대부분 플랫폼 추상화 뒤로 숨기면, 복잡성을 플랫폼팀이 소유하고 관리하는 것이 가능해짐.
  • 관측가능성(옵저버빌리티)이 플랫폼 팀에 대한 신뢰를 만든다. 패키지 번들사이즈가 어떻게 줄여졌는지.
  • 앱팀 입장에서 플랫폼 패키지는 "내가 통제할 수 없는 의존성"이므로, 변경의 영향을 예측 가능하게 만드는 것이 자체 운영권한(self-service)의 전제조건.
• 그래야 추상화 경계선을 핵심 서비스 집합으로 상향이동할 수 있으며, 각 서비스는 광범위한 애플리케이션의 유즈케이스들을 처리할 수 있다.
• 또한, 플랫폼 팀에서 높은 운영표준을 유지하여 애플리케이션 팀이 안심하고 의존할 수 있도록 하는것도 중요하다.