2019.01.31

서버리스 컴퓨팅 표준 될까?··· ‘K네이티브’의 가치와 과제

James Kobielus | InfoWorld
어떤 하나의 ‘관행’이 널리 전파되고, 수 많은 이질적인 방법들로 이를 다루는 경우가 많을 때 표준이 필요해진다. 오늘날 서버리스 컴퓨팅 시장에 적용되는 상황이다. 

PaaS(platform-as-a-service (PaaS)) 맥락에서 보면, 서버리스 컴퓨팅은 이벤트에 기반하고, 변동성이 존재하는 워크로드에 잘 맞는다. 온디맨드 방식이고, 축소 및 확장이 가능하며 효율적이고, 사용한만큼 돈을 내기 때문이다. 

개발자는 인프라를 구성할 필요 없어, 더 빨리 기능을 배포할 수 있다. 자동으로 크기가 조정되는 기능을 시작시키는 트리거를 정의할 수도 있다. 또 작업이 완료될 때 기능이 자동 종료되도록 만들 수 있다.

서버리스 컴퓨팅 모멘텀
최근 클라우드 네이티브 컴퓨팅 부문에서 서버리스 컴퓨팅과 관련한 큰 모멘텀이 형성되어 있다. 라이트스케일(RightScale)의 ‘2018년 클라우드 현황(State of the Cloud)’ 보고서에 설명되어 있듯, 이벤트가 동인이 되는 스테이트리스(stateless) 클라우드 애플리케이션이 마이크로서비스 모델을 급성장시키고 있다. 약 연간 75%의 증가 비율로 엔터프라이즈 도입이 늘어나는 중이다. 

그리고 가벼운 클라우드 기능을 대상으로 하는 서버리스 컴퓨팅의 장점과 이점은 수 많은 커머셜(상용), 오픈소스 서버리스 플랫폼을 등장시키고 있다.

많은 서버리스 환경이 퍼블릭 클라우드에서 네이티브(기본)로 지원되고 있다. AWS 람다, 애저 펑션(Azure Functions), 구글 펑션(Google Functions), IBM 클라우드 펑션(IBM Cloud Functions), 오라클 펑션(Oracle Functions)을 비롯해 서비스로서의 펑션(Function-as-a-Service) 상품에서의 증가에서 확인할 수 있듯, 서버리스 컴퓨팅은 이미 퍼블릭 클라우드 서비스에 크게 ‘통합’된 상태이다.

여기에 그치지 않는다. 프라이빗 클라우드 시장으로도 깊이 진입하기 시작했다. 지난 몇 년간, 온프레미스와 하이브리드 클라우드, 멀티클라우드 배포를 대상으로 한 다양한 대안적인 서버리스 플랫폼이 많이 등장했다. OpenWhisk, Fission, Gestalt, IronFunctions, Nuclio, Fn Project, Funktion, Fission, Kubeless, Funcatron, OpenFaaS, Webtask.io 등을 예로 들 수 있다.

그런데 이런 서버리스 플랫폼 확산으로 조기 도입자들에게 사일로 및 벤더 종속 문제가 나타났다. 현재 대부분의 서버리스 배포 도구는 AWS 람다 서비스를 중심으로 특정 사일로를 위한 기능 구현을 지원한다. 그렇지만 여러 주요 백엔드에 대한 통합을 지원하고, Node.je와 파이썬, 자바, 고 등 다양한 언어로 기능을 프래그래밍 할 수 있는 추상화 계층을 제공하는 서버리스 IDE가 증가하고 있는 추세이다. 해시코프(HashiCorp)의 테라폼(Terraform), 서버리스닷컴(Serverless.com)의 서버리스 프레임워크(Serverless Framework), 솔로닷아이오(Solo.io)의 글루(Gloo)를 예로 들 수 있다.

엔터프라이즈 애플리케이션 환경에서도 느리지만 확실하게 하이브리드 서버리스 멀티클라우드가 부상하고 있다

그러나 크로스 플랫폼(여러 플랫폼에 적용되는) 서버리스 표준에 대한 전망은 좋게 봐도 ‘흐릿한’ 정도다. 일관된 관행을 수립하고, 공급자와 사용자, 기타 이해당사자로 구성된 커뮤니티의 합의 프로세스로 관리되는 공식적이고, 문서화 되어있고, 개방적인 사양이 진짜 표준이다.

언젠가 서버리스 표준이 될 수 있는 K네이티브(Knative)
일부 업계 전문가들은 오픈소스인 K네이티브 프로젝트가 서버리스 표준화의 토대라고 주장한다. 물론 아직은 설익은 주장일 수 있다. 지난해, CNCF(Cloud Native Computing Foundation)의 후원 아래 공개된 K네이티브 프로젝트는 퍼블릭과 프라이빗, 하이브리드 등 모든 클라우드에 배포해 실행할 수 있는 콘테이너 기반의 서버리스 애플리케이션 구축을 단순화시키는 데 목적을 두고 있다. 

한편 별개의 프로젝트 리프(Project Riff)도 있다. 이는 K네이티브를 개발자 및 운영자 도구로 확장시킨다. 설치를 단순화시키고, 주요한 사용자 경험 요소를 추가할 수 있는 도구이다.

상업적인 추진력을 얻으면, K네이티브는 언젠가 여러 언어를 지원, 단 한 번만 개발하면 어느 장소에서나 실행시킬 수 있는 방식으로 서버리스 기능을 프로그래밍할 수 있게 만들 잠재력을 가진다. 
 
ⓒ Image Credit : Getty Images Bank



그러나 그런 날은 아직 멀었다. CNCF 아래 추진되는 많은 프로젝트들처럼, 진짜 표준화와 광범위한 도입이라는 결실을 맺기까지 해결해야 할 일들이 많다. CNCF는 K네이티브를 후원하기 전에, 이미 CloudEvents 사양을 규정한 전력이 있다. 이는 멀티클라우드 서버리스 애플리케이션 이동성과 재사용을 보장하는 이벤트 트리거 표준 세트이지만 충분한 추진력을 얻지 못했던 바 있다.

현재 버전 0.2인 K네이티브는 구글이 IBM 산하 레드햇 사업 부문, 피보탈, SAP와 협력해 개발했다. 현재 K네이티브에 미흡한 부분 중 하나는 아직까지는 온프레이스, 하이브리드, 멀티클라우드 배포에 맞춰진 다양한 서버리스 환경은 물론이고 AWS 람다 같은 인기 퍼블릭 서버리스 플랫폼의 기능을 흡수하지 못한다는 것이다.

K네이티브를 지원하는 벤더들
그러나 K네이티브의 주요 개발사들은 각자 보유 솔루션 포트폴리오에 K네이티브를 통합한다는 ‘중대’ 발표를 했다.

- 구글은 2018년 7월부로 구글 쿠버네티스 엔진(GKE)에서 서버리스 애드온으로 K네이티브를 지원하기 시작했다. 개발자들은 K네이티브를 활용, 클라우드 공급자 간 마이그레이션이 용이한 콘테이너 기반의 서버리스 애플리케이션을 빌드, 제공, 관리할 수 있다.




2019.01.31

서버리스 컴퓨팅 표준 될까?··· ‘K네이티브’의 가치와 과제

James Kobielus | InfoWorld
어떤 하나의 ‘관행’이 널리 전파되고, 수 많은 이질적인 방법들로 이를 다루는 경우가 많을 때 표준이 필요해진다. 오늘날 서버리스 컴퓨팅 시장에 적용되는 상황이다. 

PaaS(platform-as-a-service (PaaS)) 맥락에서 보면, 서버리스 컴퓨팅은 이벤트에 기반하고, 변동성이 존재하는 워크로드에 잘 맞는다. 온디맨드 방식이고, 축소 및 확장이 가능하며 효율적이고, 사용한만큼 돈을 내기 때문이다. 

개발자는 인프라를 구성할 필요 없어, 더 빨리 기능을 배포할 수 있다. 자동으로 크기가 조정되는 기능을 시작시키는 트리거를 정의할 수도 있다. 또 작업이 완료될 때 기능이 자동 종료되도록 만들 수 있다.

서버리스 컴퓨팅 모멘텀
최근 클라우드 네이티브 컴퓨팅 부문에서 서버리스 컴퓨팅과 관련한 큰 모멘텀이 형성되어 있다. 라이트스케일(RightScale)의 ‘2018년 클라우드 현황(State of the Cloud)’ 보고서에 설명되어 있듯, 이벤트가 동인이 되는 스테이트리스(stateless) 클라우드 애플리케이션이 마이크로서비스 모델을 급성장시키고 있다. 약 연간 75%의 증가 비율로 엔터프라이즈 도입이 늘어나는 중이다. 

그리고 가벼운 클라우드 기능을 대상으로 하는 서버리스 컴퓨팅의 장점과 이점은 수 많은 커머셜(상용), 오픈소스 서버리스 플랫폼을 등장시키고 있다.

많은 서버리스 환경이 퍼블릭 클라우드에서 네이티브(기본)로 지원되고 있다. AWS 람다, 애저 펑션(Azure Functions), 구글 펑션(Google Functions), IBM 클라우드 펑션(IBM Cloud Functions), 오라클 펑션(Oracle Functions)을 비롯해 서비스로서의 펑션(Function-as-a-Service) 상품에서의 증가에서 확인할 수 있듯, 서버리스 컴퓨팅은 이미 퍼블릭 클라우드 서비스에 크게 ‘통합’된 상태이다.

여기에 그치지 않는다. 프라이빗 클라우드 시장으로도 깊이 진입하기 시작했다. 지난 몇 년간, 온프레미스와 하이브리드 클라우드, 멀티클라우드 배포를 대상으로 한 다양한 대안적인 서버리스 플랫폼이 많이 등장했다. OpenWhisk, Fission, Gestalt, IronFunctions, Nuclio, Fn Project, Funktion, Fission, Kubeless, Funcatron, OpenFaaS, Webtask.io 등을 예로 들 수 있다.

그런데 이런 서버리스 플랫폼 확산으로 조기 도입자들에게 사일로 및 벤더 종속 문제가 나타났다. 현재 대부분의 서버리스 배포 도구는 AWS 람다 서비스를 중심으로 특정 사일로를 위한 기능 구현을 지원한다. 그렇지만 여러 주요 백엔드에 대한 통합을 지원하고, Node.je와 파이썬, 자바, 고 등 다양한 언어로 기능을 프래그래밍 할 수 있는 추상화 계층을 제공하는 서버리스 IDE가 증가하고 있는 추세이다. 해시코프(HashiCorp)의 테라폼(Terraform), 서버리스닷컴(Serverless.com)의 서버리스 프레임워크(Serverless Framework), 솔로닷아이오(Solo.io)의 글루(Gloo)를 예로 들 수 있다.

엔터프라이즈 애플리케이션 환경에서도 느리지만 확실하게 하이브리드 서버리스 멀티클라우드가 부상하고 있다

그러나 크로스 플랫폼(여러 플랫폼에 적용되는) 서버리스 표준에 대한 전망은 좋게 봐도 ‘흐릿한’ 정도다. 일관된 관행을 수립하고, 공급자와 사용자, 기타 이해당사자로 구성된 커뮤니티의 합의 프로세스로 관리되는 공식적이고, 문서화 되어있고, 개방적인 사양이 진짜 표준이다.

언젠가 서버리스 표준이 될 수 있는 K네이티브(Knative)
일부 업계 전문가들은 오픈소스인 K네이티브 프로젝트가 서버리스 표준화의 토대라고 주장한다. 물론 아직은 설익은 주장일 수 있다. 지난해, CNCF(Cloud Native Computing Foundation)의 후원 아래 공개된 K네이티브 프로젝트는 퍼블릭과 프라이빗, 하이브리드 등 모든 클라우드에 배포해 실행할 수 있는 콘테이너 기반의 서버리스 애플리케이션 구축을 단순화시키는 데 목적을 두고 있다. 

한편 별개의 프로젝트 리프(Project Riff)도 있다. 이는 K네이티브를 개발자 및 운영자 도구로 확장시킨다. 설치를 단순화시키고, 주요한 사용자 경험 요소를 추가할 수 있는 도구이다.

상업적인 추진력을 얻으면, K네이티브는 언젠가 여러 언어를 지원, 단 한 번만 개발하면 어느 장소에서나 실행시킬 수 있는 방식으로 서버리스 기능을 프로그래밍할 수 있게 만들 잠재력을 가진다. 
 
ⓒ Image Credit : Getty Images Bank



그러나 그런 날은 아직 멀었다. CNCF 아래 추진되는 많은 프로젝트들처럼, 진짜 표준화와 광범위한 도입이라는 결실을 맺기까지 해결해야 할 일들이 많다. CNCF는 K네이티브를 후원하기 전에, 이미 CloudEvents 사양을 규정한 전력이 있다. 이는 멀티클라우드 서버리스 애플리케이션 이동성과 재사용을 보장하는 이벤트 트리거 표준 세트이지만 충분한 추진력을 얻지 못했던 바 있다.

현재 버전 0.2인 K네이티브는 구글이 IBM 산하 레드햇 사업 부문, 피보탈, SAP와 협력해 개발했다. 현재 K네이티브에 미흡한 부분 중 하나는 아직까지는 온프레이스, 하이브리드, 멀티클라우드 배포에 맞춰진 다양한 서버리스 환경은 물론이고 AWS 람다 같은 인기 퍼블릭 서버리스 플랫폼의 기능을 흡수하지 못한다는 것이다.

K네이티브를 지원하는 벤더들
그러나 K네이티브의 주요 개발사들은 각자 보유 솔루션 포트폴리오에 K네이티브를 통합한다는 ‘중대’ 발표를 했다.

- 구글은 2018년 7월부로 구글 쿠버네티스 엔진(GKE)에서 서버리스 애드온으로 K네이티브를 지원하기 시작했다. 개발자들은 K네이티브를 활용, 클라우드 공급자 간 마이그레이션이 용이한 콘테이너 기반의 서버리스 애플리케이션을 빌드, 제공, 관리할 수 있다.


X