Backstage?
An open platform for building developer portals.
영상에서 백스테이지는 ‘개발자 포탈’ 제작을 위한 오픈 ‘플랫폼’이라고 한다. 음… 생소한 단어는 없지만 좀 모호하다는 느낌이 든다. 무얼 하려는거지?
플랫폼 엔지니어링?
backstage가 나온 배경엔 플랫폼 엔지니어링이 있다.
플랫폼 엔지니어링이라는 용어와 개념이 나오기 이전에도 이런 어려움은 있었다. 예를 들면 쿠버네티스는 여러 컨테이너 워크로드를 관리하기 ‘좋은’ 오픈 소스이지만, 학습 비용과 학습 곡선이 만만치 않다. AWS의 수 많은 서비스도 마찬가지이다. 필수적이지만, 모든 것이 각자의 서비스에 필요하진 않다. 오히려 이런 것들이 서비스를 개발하고 운영하는데 그 이상을 알아야 하는 부담을 주게 된다.
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era
“클라우드 네이티브 시대에 셀프 서비스가 가능한 툴체인과 워크플로 설계”에 대한 엔지니어링이다 라고 정의한다. 넓게 해석하자면, 플랫폼 엔지니어링은 클라우드 네이티브 서비스를 하며 문제점인, 개발 조직 ‘스스로’ 서비스 하는 것에 대한 어려움을 엔지니어링으로 해결하려는 것이다.
하지만 정의가 확립되었다기 보다 만들어지고 있는 단계이다(관련 국내 커뮤니티인 AWSKRUG 플랫폼 엔지니어링 소모임에서도 그러한 의견이다). 그래서 아주 명확하게 정리하고 넘어갈 순 없지만, 이어서 소개하는, 좀 더 구체적인 대상인 IDP 그리고 오픈된 IDP인 Backstage을 통해서 더 잘 이해할 수 있을 것이다. 참조한 플랫폼 엔지니어링 org의 블로그 글도 한번 읽어 보자.
(내부) 개발자 포탈?
오늘날의 개발자가 코딩(dev)만 하지 않는다. AWS 같은 클라우드 서비스를 이용해 배포하고 운영하며(ops), 보안(sec), 비용(fin) 역시 통합과 관측이 ‘가능’하고 개발 주기에서 관리’해야’ 한다(이러한 것들이 서비스로써 제공된다고 하려다가… 이정도면 실패한 서비스 아닐까?). 아! AI(ml)도 빠질 수 없다!
이 중 특정 영역에서 작업을 했더라도 나중에 쉽게 잊혀지기 마련이다. 그래서 그 간극을 문서로 채워보려 하지만, 문서는 파편화 되기 쉽다. 그리고 개발자가 집중해야 하는 역할은 역시 개발(dev)이다.
내부 개발자 플랫폼(Internal Developer Platform; IDP)는 이런 문제를 해결하기 위해 개발자에게 제공하는 플랫폼이다:
An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service. An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies
IDP 개념의 정의는 매우 넒지만, 중요한 것은 내부 개발자가 스스로 서비스 할 수 있도록:
•
인지 부하를 줄인다.
•
그러나 컨텍스트와 기반 기술에 대해 ‘모르게끔’ 추상화를 하지 않는다(without abstracting away …).
dev 외에 인지 부하에 해당하는 ops, sec, fin, ml, … 등을 최대한 없애 인지 부하를 줄인다. 하지만 컨텍스트와 기반 기술에 대해 완전히 가리지 않는다(abstract away는 omit, ignore의 뜻이 있다). 이 부분이 참신하다 생각했고 주목하게 됐다. 섣부른 추상화는 개발자에게 스스로 서비스할 수 있을만큼의 컨텍스트와 기반 기술을 전달하지 못한다고 반문하는 듯 하다:
When using these IDPs, developers can pick the right level of abstraction to run their apps and services, depending on their preference, i.e. do they like messing around with Helm charts, YAML files and Terraform modules? Great, they can do so. Are they a junior frontend who doesn’t care if the app is running on EKS? Fantastic, they can just self-serve an environment that comes fully provisioned with everything they need to deploy and test their code, without worrying where it runs.
난 마침 ‘섣부른 추상화’에 대한 예시로 “helm chart의 values(yaml)”를 생각하고 있었다. 쿠버네티스 매니페스트를 전혀 몰라도 사용할 수 있게끔 helm values로 추상화하는 것은 쉽지 않다(템플릿이라는 방법 자체의 한계도 있다). 다르게 말하면 결국은 템플릿을 들여다보고 싶은 욕구가 생기거나 그래야 문제가 해결되는 경우가 있다(추상화가 충분치 않았다는 뜻이다).
그래서 “내부(Internal)”란 팀의 ‘적절하고도(right) 선호하는(preference) 수준’을 나타내는 수식어이다.
IDP에 대한 구성 요소를 소개하는 글을 더 읽어보자:
Backstage
빌드업이 길었다… 다시 돌아와, backstage는 이런 IDP를 만들 수 있는 오픈 소스 도구이다. 정확히는 ‘개발자 포탈’(developer platform)을 만드는 플랫폼이라고 한다. 나 역시 조금 모호한 플랫폼 엔지니어링과 IDP라는 개념을 이 backstage를 통해 구체화 시켜 보려고 한다.
backstage는 Spotify에서 개발하고 CNCF에 기부했다. 실제로 그 회사 내부 목적과 사용 사례에 맞게 재단되어 있고, 큰 규모의 조직에서 ‘문서화’ 기능에 집중한 IDP이다(현재 IDP org의 공식 설명으론, 운영 기능의 부족으로 IDP로써 보기 어렵지만, IDP와의 시너지가 좋다고 한다).
backstage에서 말하는 개발자 포탈이란 크게 세가지로 구성된다:
•
Software Catalogs
•
Software Templates
•
TechDocs
Software Catalog
소프트웨어 카탈로그는 조직 내 모든 컴포넌트의 소유권(ownership)과 같은 메타데이터를 중앙으로 모아 시각화하고 추적한다.
소프트웨어라고 하는 것은 서비스 뿐만 아니라 라이브러리나 데이터 파이프라인 등 코드로 이뤄진 모든 컴포넌트를 포함한다(컴포넌트 유형으로 정의하기 나름이다). 따라서 컴포넌트의 API 명세가 있으며, 플러그인을 통해 쿠버네티스를 백엔드로 사용하면 CRD처럼 사용할 수 있어 보인다(인지 부하를 줄이려는거 맞지..?)
Software Template
소프트웨어 템플릿은 컴포넌트를 새로 만들 때 정해진 템플릿에 따라 backstage에 등록하는 방법이다. 크게 세 단계로 진행된다. 1. 생성 단계에서 변수를 입력하고, 2. 템플릿을 실행하면 3. 새 컴포넌트의 부트스트랩 코드를 github repo 같은 곳에 게시하게 된다.
사실 이게 github 조직의 템플릿을 활용해 새 repo를 만드는 것에 비해 어떤 이점이 있는지는 아직 잘 모르겠다. github 조직과 repo의 레이블로는 다 표현할 수 없는 카탈로그의 메타데이터 기능 때문에 (굳이?) backstage로 통합하는거 아닌가 싶은 느낌이다.
TechDocs
말 그대로, 조직 내의 기술 문서를 다루는 단위이다. docs-like-code solution이라는 표현을 쓴다. 문서화 작업이 코드에 비해 뒤쳐지지 않고 썩지 않도록, 코드 가까운 곳에서 쉽게 작성하고 한 군데에 모아 사용할 수 있게 한 것 같다.
플러그인을 통한 확장성
그 외에 구성 요소는 플러그인을 통해 확장할 수 있도록 생태계를 만들어놨다.
이건 backstage가 ‘오픈’ 플랫폼이기 때문에, ‘내부’ 개발자 플랫폼을 만드는데에 있어서 한계를 극복하기 위함인것 같다(배치된다고도 보인다. 아니 인지 부하를 줄일 수 있는 것 맞아?)(뭐 돈내는 서비스가 아닌 오픈 소스인게 어디야 라는 생각도 든다 ㅎ).
다만, 커뮤니티에서 이야기 나눈(일방적으로 들은 것에 가깝긴 하다 ㅎㅎ) 결과, backstage의 가치는 IDP를 만드는데에 공수를 덜 들일 수 있다는 점에 있다고 생각한다. 실제로 많은 국내 회사에서 플랫폼 엔지니어링에 관심과 필요를 느끼지만, 시작하는데 있어서 부담을 더 크게 느낀다고 한다. 내부 조직에 커스텀한 UI부터, 오픈 소스나 서비스 통합보다 쉬운 백엔드 코드를 만든다는 것이 부담으로 다가온다는 의견이 지배적이다. backstage는 카탈로그와 템플릿으로 미리 정의된 UI 컴포넌트와 플러그인을 통한 백엔드 확장으로 이를 쉽게 시작할 수 있게 해줄 것이라 기대하고 있다.
습득 교훈
backstage hands-on을 해보기 전에 간단하게 관련한 개념을 정리하려고 했는데 간단하지 않았다 ㅎㅎ. 그래도 플랫폼 엔지니어링, IDP에 대해 한번 정리해 볼 수 있었다. 개념들이 모호하다고 방치해둔다고 이해되진 않는다. 또, 명확해진 후, 나중에 따라 갈 때 해야 할 고민들이 생략되기 때문에 의미 있다고 느껴졌다. 아무튼 이젠 시간 내어서 backstage hands-on을 해보아야 한다(이러한 개념을 첫 만남에 고봉밥으로 꾹꾹 눌러 담아 주신 병찬님께 감사드립니다 ).
).•
플랫폼 엔지니어링은, 클라우드 네이티브 시대에 개발 조직이 ‘스스로 서비스’ 가능하게 하는 툴체인과 워크플로에 대한 엔지니어링이다.
•
IDP(internal developer platform, 내부 개발자 플랫폼)는 엔드 사용자인 내부 개발자가 ‘스스로 서비스’ 할 수 있도록 개발한 플랫폼이다.
◦
이 때 개발자의 인지 부하는 줄이되 컨텍스트와 기반 기술을 완전히 가리지 않고, 팀에게 적절하며 팀이 선호하는 수준으로 추상화한다.
•
backstage는 개발자 포탈(developer portal)을 만들 수 있는 오픈 플랫폼이다; 넓은 의미의 IDP 제작 도구이다.
◦
software catalog는 조직의 컴포넌트(=소프트웨어) 소유권과 메타데이터를 중앙에서 추적, 관리 그리고 시각화하게 한다.
◦
software template은 컴포넌트를 생성하는 템플릿이다.
◦
TechDocs는 docs-like-code로써 내부 개발 조직 문서를 중앙화하여 작성하고 검색하기 쉽게 도와준다.