2021.03.10

클라우드 서버리스 플랫폼을 선택하는 방법

Martin Heller | InfoWorld
클라우드에서 전체 용량으로 24/7 서버 팜을 운영할 경우 비용이 천정부지로 치솟을 수 있다. 필요 없을 때 용량의 대부분을 끌 수 있다면 어떨까? 이 아이디어를 논리적으로 한 단계 더 발전시켜 보자. 서버가 필요할 때만 불러와서 해당 부하를 처리하는 데 필요한 만큼의 용량만 제공할 수 있다면 어떨까? 
 
ⓒ Getty Images Bank

그래서 등장한 것이 서버리스 컴퓨팅이다. 서버리스 컴퓨팅은 클라우드 서비스 업체가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지만 동적으로 할당한 다음 그 부분에 대해서만 비용을 청구하는 클라우드 실행 모델이다. 

즉, 서버리스 컴퓨팅은 사용한 만큼만 비용을 내는 온디맨드 방식의 백엔드 컴퓨팅이다. 서버리스 엔드포인트로 요청이 오면 백엔드는 이미 해당 코드를 포함하고 있는 기존 “핫” 엔드포인트를 재사용하거나, 풀에서 리소스를 할당하고 맞춤 설정하거나, 새 엔드포인트를 인스턴스화하고 맞춤 설정한다. 일반적으로 인프라는 수신되는 요청을 처리하는 데 필요한 만큼의 인스턴스를 실행하며 냉각기가 지난 후 유휴 인스턴스를 해제한다. 

물론 “서버리스”는 딱 맞는 용어가 아니다. 이 모델도 서버를 사용한다. 다만 사용자가 서버를 관리할 필요가 없을 뿐이다. 서버리스 코드를 실행하는 컨테이너 또는 기타 리소스는 일반적으로 클라우드에서 실행되지만 엣지 접속 포인트에서 실행될 수도 있다. 

FaaS(Function as a service, 서비스형 함수)는 다양한 서버리스 아키텍처를 보여준다. FaaS에서는 사용자가 함수의 코드를 쓰면, 인프라가 런타임 환경을 제공하고 코드를 로드해서 실행하고 런타임 라이프사이클을 제어하는 작업을 담당한다. FaaS 모듈은 웹훅, HTTP 요청, 스트림, 스토리지 버킷, 데이터베이스 및 다른 구성 요소와 통합되어 서버리스 애플리케이션을 형성할 수 있다. 
 

서버리스 컴퓨팅의 함정 

서버리스 컴퓨팅은 매력적이고 서버리스로 전환해서 클라우드 비용을 60% 이상 줄인 사례도 있지만, 몇 가지 잠재적인 문제점도 있다. 가장 일반적인 문제는 콜드 스타트(cold start)다. 

요청이 들어온 시점에 가용한 “핫” 엔드포인트가 없는 경우 인프라는 새 컨테이너를 인스턴스화해서 사용자의 코드를 사용해 초기화해야 한다. 인스턴스화에는 몇 초 정도가 소요될 수 있는데, 한자릿수 ms 단위의 응답이 당연시되는 서비스에서는 상당히 긴 시간이다. 이런 콜드 스타트는 피해야 하는 현상이다. 많은 서버리스 서비스가 체인으로 연결되고 모두 콜드 상태가 되는 경우, 지연 시간은 더욱 길어질 수 있다. 

콜드 스타트를 피하는 방법에는 몇 가지가 있다. keep-alive 핑을 사용하는 방법이 있지만, 이는 사용되는 실행 시간을 늘리고 따라서 비용도 늘어나게 된다. 또 다른 방법은 서버리스 인프라에서 컨테이너보다 가벼운 아키텍처를 사용하는 것이다. 세 번째 방법은 연결이 완전히 설정될 때까지 기다리지 않고 클라이언트 요청이 엔드포인트와 보안 핸드셰이크를 시작하는 즉시 런타임 프로세스를 시작하는 것이다. 또한 컨테이너를 항상 “웜” 상태로 유지해서 클라우드의 확장 구성을 언제든 통과할 수 있도록 하는 방법도 있다. 

서버리스에 영향을 미칠 수 있는 두 번째 문제는 쓰로틀링(Throttling)이다. 많은 서비스는 비용 억제를 위해 사용할 수 있는 서버리스 인스턴스의 수에 제한을 둔다. 트래픽이 많은 기간 동안 인스턴스의 수가 한도에 이르면 이후 추가로 수신되는 요청에 대한 응답이 지연되거나 실패할 수도 있다. 쓰로틀링 문제를 해결하기 위해서는 DoS 공격이나 시스템의 다른 부분에 존재하는 버그로 인한 통제되지 않는 사용을 차단하면서 정상적인 피크 사용량을 소화할 수 있도록 신중하게 한도를 조정해야 한다. 

서버리스 아키텍처의 세 번째 문제는 스토리지 계층이 피크 트래픽을 처리하지 못할 수 있고, 사용 가능한 인스턴스가 풍부함에도 불구하고 실행 중인 서버리스 프로세스를 백업할 수 있다는 점이다. 이 문제의 한 가지 해결 방법은 피크 시점의 데이터를 흡수한 다음 데이터베이스가 디스크에 데이터를 커밋할 수 있게 되는 즉시 데이터베이스로 넘겨주는 메모리 상주 캐시 또는 큐를 사용하는 것이다. 

모니터링 및 디버깅 툴의 부재는 이러한 모든 문제를 더 악화시키고 진단을 더욱 어렵게 한다. 업체 종속성(Vendor Lock-in)은 위험 목록에 포함하지 않았는데, 앞으로 살펴보겠지만 업체 종속성은 문제보다는 타협에 가깝다. 
 

AWS 람다 및 관련 서비스 

AWS 람다(Lambda)는 FaaS 상품이다. AWS 람다가 아마존의 유일한 서버리스 제품이라고 생각할 수 있지만 그렇지 않다. AWS 람다는 현재 10여 개에 이르는 AWS 서버리스 제품 중 하나다. 또한 AWS 람다(2014)가 최초의 FaaS 서비스라고 생각할 수도 있는데, 그 전에 짐키(Zimki, 2006)와 구글 앱 엔진(2008), 그리고 파이클라우드(PiCloud, 2010)가 있었다. 

AWS 람다는 파이썬, Node.js, 루비, 자바, C#, 파워셸, 구글 고로 작성된 스테이트리스(stateless) 함수 코드를 지원한다. 람다 함수는 아마존 S3로의 객체 업로드, 아마존 SNS 알림, 또는 API 동작과 같은 이벤트에 반응해서 실행된다. 람다 함수는 자동으로 500MB의 임시 스크래치 디렉터리를 받으며, 영구 상태를 위해 아마존 S3, 아마존 다이나모DB(DynamoDB) 또는 다른 인터넷 스토리지 서비스를 사용할 수 있다. 람다 함수는 아마존 리눅스에서 지원되는 모든 언어를 사용해서 프로세스를 실행하고 라이브러리를 호출할 수 있다. 람다 함수는 모든 AWS 지역에서 실행 가능하다. 

언급할 만한 그 외의 AWS 서버리스 제품도 있다. 람다@엣지(Lambda@Edge)는 아마존 클라우드프론트(CloudFront) CDN 이벤트에 대응해 200개 이상의 AWS 엣지 위치에서 람다 함수를 실행할 수 있게 해준다. 아마존 다이나모DB는 빠르고 유연한 키-값 및 문서 데이터베이스 서비스로, 대규모 환경에서 일관적인 한자릿수 ms 수준의 지연을 제공한다. 아마존 키네시스(Kinesis)는 AWS에서 데이터를 스트리밍하기 위한 플랫폼이다. AWS 그린그래스(Greengrass)로 로컬의 연결된 디바이스(예를 들어 IoT용 컨트롤러)에서 람다 함수를 실행할 수도 있다. 

오픈소스 AWS SAM(AWS Serverless Application Model)은 서버리스 애플리케이션 및 서비스를 모델링하고 배포할 수 있다. AWS 람다는 SAM 외에 8개의 오픈소스 및 서드파티 프레임워크를 지원한다. 

AWS 서버리스 애플리케이션 리포지토리(AWS Serverless Application Repository)는 다양한 사용례를 위한 서버리스 애플리케이션과 애플리케이션 구성요소를 찾아서 재사용할 수 있게 해준다. 아마존 클라우드워치(CloudWatch)를 사용해서 서버리스 애플리케이션을 모니터링하고 AWS 엑스레이(X-Ray)를 사용해 분석 및 디버깅할 수 있다. 마지막으로, AWS 람다는 최근 람다와 모니터링, 관찰, 보안 및 거버넌스 툴을 손쉽게 통합할 수 있는 새로운 방법인 람다 익스텐션(Lambda Extension) 프리뷰를 발표했다. 
 

마이크로소프트 애저 펑션 

마이크로소프트 애저 펑션(Microsoft Azure Functions) 역시 복잡한 오케스트레이션 문제를 해결할 수 있는 이벤트 기반의 서버리스 컴퓨팅 플랫폼이다. 클라우드에서 대규모로 설정, 배포, 운영할 필요 없이 로컬에서 애저 펑션을 구축하고 디버깅할 수 있으며, 트리거와 바인딩을 사용해서 서비스를 통합할 수 있다.  

C#, F#, 자바, 자바스크립트(Node.js), 파워셸 또는 파이썬으로 애저 펑션을 코딩할 수 있다. 하나의 애저 펑션 앱에서 위 언어 중 하나만 사용할 수 있다. 비주얼 스튜디오, 비주얼 스튜디오 코드(아래 스크린샷 참조), 인텔리J, 이클립스 및 애저 펑션 코어 툴에서 로컬로 애저 펑션을 개발할 수 있다. 또는 애저 포털에서 작은 애저 펑션을 직접 편집하는 것도 가능하다. 

듀어러블 펑션(Durable Functions)은 애저 펑션의 확장 프로그램으로, 서버리스 컴퓨팅 환경에서 스테이트풀(stateful) 함수를 쓸 수 있게 해준다. 듀어러블 펑션을 사용하면 애저 펑션 프로그래밍 모델을 사용해 개체 함수를 작성하는 방법으로 오케스트레이터 함수와 스테이트풀 개체를 써서 스테이트풀 워크플로우를 정의할 수 있다. 

트리거는 함수의 실행을 유발한다. 트리거는 함수가 어떻게 호출되는지를 정의하며, 함수에는 정확히 하나의 트리거만 있어야 한다. 트리거에는 연결된 데이터가 있으며, 이 데이터는 보통 함수의 페이로드로 제공된다. 

함수 바인딩은 함수에 다른 리소스를 선언적으로 연결하는 방법이다. 바인딩은 입력 바인딩, 출력 바인딩 또는 두 가지 모두로 연결될 수 있다. 바인딩에서 오는 데이터는 함수에 매개변수로 제공된다. 
 
ⓒ IDG
 

구글 클라우드 펑션 

구글 클라우드 펑션(Google Cloud Functions)은 확장 가능한 종량제 FaaS 플랫폼이다. 모니터링, 로깅, 디버깅 기능을 통합했고 역할 및 함수 수준에서 보안을 내장했으며, 하이브리드 클라우드와 멀티클라우드 시나리오를 위한 주요 네트워킹 기능을 제공한다. 트리거를 통해 구글 클라우드 또는 서드파티 클라우드 서비스에 연결해서 까다로운 오케스트레이션 문제를 원활하게 해결할 수 있게 해준다. 

구글 클라우드 펑션은 구글 고, 자바, Node.js(아래 스크린샷 참조), 파이썬 코드를 지원한다. 클라우드 펑션은 GET, PUT, POST, DELETE, OPTIONS와 같은 일반적인 HTTP 요청 방법을 사용한 HTTP 요청과 클라우드 인프라에서 이벤트를 처리하기 위한 백그라운드 함수를 지원한다. 클라우드 펑션의 자동 테스트 및 배포를 위해 클라우드 빌드(Cloud Build) 또는 다른 CI/CD 플랫폼을 깃허브(GitHub), 비트버킷(Bitbucket), 클라우드 소스 리포지토리(Cloud Source Repositories)와 같은 소스 코드 리포지토리와 함께 사용할 수 있다. 또한 로컬 시스템에서 클라우드 펑션을 개발하고 배포할 수도 있다. 
 
ⓒ IDG
 

IBM 클라우드 펑션 

아파치 오픈위스크(OpenWhisk)를 기반으로 하는 IBM 클라우드 펑션(IBM Cloud Functions)은 필요에 따라 실행 및 확장되는 가벼운 코드를 개발하기 위한 다중 언어 지원 서비스형 함수 프로그래밍 플랫폼이다. Node.js, 파이썬, 스위프트, PHP로 IBM 클라우드 펑션을 개발할 수 있다. IBM이 자랑하는 부분은 이벤트 트리거 작업 워크플로우 내에서 클라우드 펑션과 왓슨 API가 통합되어 애플리케이션 데이터의 인지 분석을 서버리스 워크플로우의 일부로 만들 수 있다는 것이다. 
 
ⓒ IDG
 

오라클 클라우드 펑션과 Fn 프로젝트 

오라클 클라우드 펑션(Oracle Cloud Functions)은 개발자가 인프라를 관리하지 않고도 애플리케이션을 생성, 실행, 확장할 수 있게 해주는 서버리스 플랫폼이다. 함수는 오라클 클라우드 인프라(Oracle Cloud Infrastructure), 플랫폼 서비스 및 SaaS 애플리케이션과 통합된다. 오라클 클라우드 펑션은 오픈소스 Fn 프로젝트를 기반으로 하므로 개발자는 다른 클라우드 및 온프레미스 환경에 이식 가능한 애플리케이션을 만들 수 있다. 오라클 클라우드 펑션은 파이썬, 고, 자바, 루비, Node.js로 된 코드를 지원한다. 
 



2021.03.10

클라우드 서버리스 플랫폼을 선택하는 방법

Martin Heller | InfoWorld
클라우드에서 전체 용량으로 24/7 서버 팜을 운영할 경우 비용이 천정부지로 치솟을 수 있다. 필요 없을 때 용량의 대부분을 끌 수 있다면 어떨까? 이 아이디어를 논리적으로 한 단계 더 발전시켜 보자. 서버가 필요할 때만 불러와서 해당 부하를 처리하는 데 필요한 만큼의 용량만 제공할 수 있다면 어떨까? 
 
ⓒ Getty Images Bank

그래서 등장한 것이 서버리스 컴퓨팅이다. 서버리스 컴퓨팅은 클라우드 서비스 업체가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지만 동적으로 할당한 다음 그 부분에 대해서만 비용을 청구하는 클라우드 실행 모델이다. 

즉, 서버리스 컴퓨팅은 사용한 만큼만 비용을 내는 온디맨드 방식의 백엔드 컴퓨팅이다. 서버리스 엔드포인트로 요청이 오면 백엔드는 이미 해당 코드를 포함하고 있는 기존 “핫” 엔드포인트를 재사용하거나, 풀에서 리소스를 할당하고 맞춤 설정하거나, 새 엔드포인트를 인스턴스화하고 맞춤 설정한다. 일반적으로 인프라는 수신되는 요청을 처리하는 데 필요한 만큼의 인스턴스를 실행하며 냉각기가 지난 후 유휴 인스턴스를 해제한다. 

물론 “서버리스”는 딱 맞는 용어가 아니다. 이 모델도 서버를 사용한다. 다만 사용자가 서버를 관리할 필요가 없을 뿐이다. 서버리스 코드를 실행하는 컨테이너 또는 기타 리소스는 일반적으로 클라우드에서 실행되지만 엣지 접속 포인트에서 실행될 수도 있다. 

FaaS(Function as a service, 서비스형 함수)는 다양한 서버리스 아키텍처를 보여준다. FaaS에서는 사용자가 함수의 코드를 쓰면, 인프라가 런타임 환경을 제공하고 코드를 로드해서 실행하고 런타임 라이프사이클을 제어하는 작업을 담당한다. FaaS 모듈은 웹훅, HTTP 요청, 스트림, 스토리지 버킷, 데이터베이스 및 다른 구성 요소와 통합되어 서버리스 애플리케이션을 형성할 수 있다. 
 

서버리스 컴퓨팅의 함정 

서버리스 컴퓨팅은 매력적이고 서버리스로 전환해서 클라우드 비용을 60% 이상 줄인 사례도 있지만, 몇 가지 잠재적인 문제점도 있다. 가장 일반적인 문제는 콜드 스타트(cold start)다. 

요청이 들어온 시점에 가용한 “핫” 엔드포인트가 없는 경우 인프라는 새 컨테이너를 인스턴스화해서 사용자의 코드를 사용해 초기화해야 한다. 인스턴스화에는 몇 초 정도가 소요될 수 있는데, 한자릿수 ms 단위의 응답이 당연시되는 서비스에서는 상당히 긴 시간이다. 이런 콜드 스타트는 피해야 하는 현상이다. 많은 서버리스 서비스가 체인으로 연결되고 모두 콜드 상태가 되는 경우, 지연 시간은 더욱 길어질 수 있다. 

콜드 스타트를 피하는 방법에는 몇 가지가 있다. keep-alive 핑을 사용하는 방법이 있지만, 이는 사용되는 실행 시간을 늘리고 따라서 비용도 늘어나게 된다. 또 다른 방법은 서버리스 인프라에서 컨테이너보다 가벼운 아키텍처를 사용하는 것이다. 세 번째 방법은 연결이 완전히 설정될 때까지 기다리지 않고 클라이언트 요청이 엔드포인트와 보안 핸드셰이크를 시작하는 즉시 런타임 프로세스를 시작하는 것이다. 또한 컨테이너를 항상 “웜” 상태로 유지해서 클라우드의 확장 구성을 언제든 통과할 수 있도록 하는 방법도 있다. 

서버리스에 영향을 미칠 수 있는 두 번째 문제는 쓰로틀링(Throttling)이다. 많은 서비스는 비용 억제를 위해 사용할 수 있는 서버리스 인스턴스의 수에 제한을 둔다. 트래픽이 많은 기간 동안 인스턴스의 수가 한도에 이르면 이후 추가로 수신되는 요청에 대한 응답이 지연되거나 실패할 수도 있다. 쓰로틀링 문제를 해결하기 위해서는 DoS 공격이나 시스템의 다른 부분에 존재하는 버그로 인한 통제되지 않는 사용을 차단하면서 정상적인 피크 사용량을 소화할 수 있도록 신중하게 한도를 조정해야 한다. 

서버리스 아키텍처의 세 번째 문제는 스토리지 계층이 피크 트래픽을 처리하지 못할 수 있고, 사용 가능한 인스턴스가 풍부함에도 불구하고 실행 중인 서버리스 프로세스를 백업할 수 있다는 점이다. 이 문제의 한 가지 해결 방법은 피크 시점의 데이터를 흡수한 다음 데이터베이스가 디스크에 데이터를 커밋할 수 있게 되는 즉시 데이터베이스로 넘겨주는 메모리 상주 캐시 또는 큐를 사용하는 것이다. 

모니터링 및 디버깅 툴의 부재는 이러한 모든 문제를 더 악화시키고 진단을 더욱 어렵게 한다. 업체 종속성(Vendor Lock-in)은 위험 목록에 포함하지 않았는데, 앞으로 살펴보겠지만 업체 종속성은 문제보다는 타협에 가깝다. 
 

AWS 람다 및 관련 서비스 

AWS 람다(Lambda)는 FaaS 상품이다. AWS 람다가 아마존의 유일한 서버리스 제품이라고 생각할 수 있지만 그렇지 않다. AWS 람다는 현재 10여 개에 이르는 AWS 서버리스 제품 중 하나다. 또한 AWS 람다(2014)가 최초의 FaaS 서비스라고 생각할 수도 있는데, 그 전에 짐키(Zimki, 2006)와 구글 앱 엔진(2008), 그리고 파이클라우드(PiCloud, 2010)가 있었다. 

AWS 람다는 파이썬, Node.js, 루비, 자바, C#, 파워셸, 구글 고로 작성된 스테이트리스(stateless) 함수 코드를 지원한다. 람다 함수는 아마존 S3로의 객체 업로드, 아마존 SNS 알림, 또는 API 동작과 같은 이벤트에 반응해서 실행된다. 람다 함수는 자동으로 500MB의 임시 스크래치 디렉터리를 받으며, 영구 상태를 위해 아마존 S3, 아마존 다이나모DB(DynamoDB) 또는 다른 인터넷 스토리지 서비스를 사용할 수 있다. 람다 함수는 아마존 리눅스에서 지원되는 모든 언어를 사용해서 프로세스를 실행하고 라이브러리를 호출할 수 있다. 람다 함수는 모든 AWS 지역에서 실행 가능하다. 

언급할 만한 그 외의 AWS 서버리스 제품도 있다. 람다@엣지(Lambda@Edge)는 아마존 클라우드프론트(CloudFront) CDN 이벤트에 대응해 200개 이상의 AWS 엣지 위치에서 람다 함수를 실행할 수 있게 해준다. 아마존 다이나모DB는 빠르고 유연한 키-값 및 문서 데이터베이스 서비스로, 대규모 환경에서 일관적인 한자릿수 ms 수준의 지연을 제공한다. 아마존 키네시스(Kinesis)는 AWS에서 데이터를 스트리밍하기 위한 플랫폼이다. AWS 그린그래스(Greengrass)로 로컬의 연결된 디바이스(예를 들어 IoT용 컨트롤러)에서 람다 함수를 실행할 수도 있다. 

오픈소스 AWS SAM(AWS Serverless Application Model)은 서버리스 애플리케이션 및 서비스를 모델링하고 배포할 수 있다. AWS 람다는 SAM 외에 8개의 오픈소스 및 서드파티 프레임워크를 지원한다. 

AWS 서버리스 애플리케이션 리포지토리(AWS Serverless Application Repository)는 다양한 사용례를 위한 서버리스 애플리케이션과 애플리케이션 구성요소를 찾아서 재사용할 수 있게 해준다. 아마존 클라우드워치(CloudWatch)를 사용해서 서버리스 애플리케이션을 모니터링하고 AWS 엑스레이(X-Ray)를 사용해 분석 및 디버깅할 수 있다. 마지막으로, AWS 람다는 최근 람다와 모니터링, 관찰, 보안 및 거버넌스 툴을 손쉽게 통합할 수 있는 새로운 방법인 람다 익스텐션(Lambda Extension) 프리뷰를 발표했다. 
 

마이크로소프트 애저 펑션 

마이크로소프트 애저 펑션(Microsoft Azure Functions) 역시 복잡한 오케스트레이션 문제를 해결할 수 있는 이벤트 기반의 서버리스 컴퓨팅 플랫폼이다. 클라우드에서 대규모로 설정, 배포, 운영할 필요 없이 로컬에서 애저 펑션을 구축하고 디버깅할 수 있으며, 트리거와 바인딩을 사용해서 서비스를 통합할 수 있다.  

C#, F#, 자바, 자바스크립트(Node.js), 파워셸 또는 파이썬으로 애저 펑션을 코딩할 수 있다. 하나의 애저 펑션 앱에서 위 언어 중 하나만 사용할 수 있다. 비주얼 스튜디오, 비주얼 스튜디오 코드(아래 스크린샷 참조), 인텔리J, 이클립스 및 애저 펑션 코어 툴에서 로컬로 애저 펑션을 개발할 수 있다. 또는 애저 포털에서 작은 애저 펑션을 직접 편집하는 것도 가능하다. 

듀어러블 펑션(Durable Functions)은 애저 펑션의 확장 프로그램으로, 서버리스 컴퓨팅 환경에서 스테이트풀(stateful) 함수를 쓸 수 있게 해준다. 듀어러블 펑션을 사용하면 애저 펑션 프로그래밍 모델을 사용해 개체 함수를 작성하는 방법으로 오케스트레이터 함수와 스테이트풀 개체를 써서 스테이트풀 워크플로우를 정의할 수 있다. 

트리거는 함수의 실행을 유발한다. 트리거는 함수가 어떻게 호출되는지를 정의하며, 함수에는 정확히 하나의 트리거만 있어야 한다. 트리거에는 연결된 데이터가 있으며, 이 데이터는 보통 함수의 페이로드로 제공된다. 

함수 바인딩은 함수에 다른 리소스를 선언적으로 연결하는 방법이다. 바인딩은 입력 바인딩, 출력 바인딩 또는 두 가지 모두로 연결될 수 있다. 바인딩에서 오는 데이터는 함수에 매개변수로 제공된다. 
 
ⓒ IDG
 

구글 클라우드 펑션 

구글 클라우드 펑션(Google Cloud Functions)은 확장 가능한 종량제 FaaS 플랫폼이다. 모니터링, 로깅, 디버깅 기능을 통합했고 역할 및 함수 수준에서 보안을 내장했으며, 하이브리드 클라우드와 멀티클라우드 시나리오를 위한 주요 네트워킹 기능을 제공한다. 트리거를 통해 구글 클라우드 또는 서드파티 클라우드 서비스에 연결해서 까다로운 오케스트레이션 문제를 원활하게 해결할 수 있게 해준다. 

구글 클라우드 펑션은 구글 고, 자바, Node.js(아래 스크린샷 참조), 파이썬 코드를 지원한다. 클라우드 펑션은 GET, PUT, POST, DELETE, OPTIONS와 같은 일반적인 HTTP 요청 방법을 사용한 HTTP 요청과 클라우드 인프라에서 이벤트를 처리하기 위한 백그라운드 함수를 지원한다. 클라우드 펑션의 자동 테스트 및 배포를 위해 클라우드 빌드(Cloud Build) 또는 다른 CI/CD 플랫폼을 깃허브(GitHub), 비트버킷(Bitbucket), 클라우드 소스 리포지토리(Cloud Source Repositories)와 같은 소스 코드 리포지토리와 함께 사용할 수 있다. 또한 로컬 시스템에서 클라우드 펑션을 개발하고 배포할 수도 있다. 
 
ⓒ IDG
 

IBM 클라우드 펑션 

아파치 오픈위스크(OpenWhisk)를 기반으로 하는 IBM 클라우드 펑션(IBM Cloud Functions)은 필요에 따라 실행 및 확장되는 가벼운 코드를 개발하기 위한 다중 언어 지원 서비스형 함수 프로그래밍 플랫폼이다. Node.js, 파이썬, 스위프트, PHP로 IBM 클라우드 펑션을 개발할 수 있다. IBM이 자랑하는 부분은 이벤트 트리거 작업 워크플로우 내에서 클라우드 펑션과 왓슨 API가 통합되어 애플리케이션 데이터의 인지 분석을 서버리스 워크플로우의 일부로 만들 수 있다는 것이다. 
 
ⓒ IDG
 

오라클 클라우드 펑션과 Fn 프로젝트 

오라클 클라우드 펑션(Oracle Cloud Functions)은 개발자가 인프라를 관리하지 않고도 애플리케이션을 생성, 실행, 확장할 수 있게 해주는 서버리스 플랫폼이다. 함수는 오라클 클라우드 인프라(Oracle Cloud Infrastructure), 플랫폼 서비스 및 SaaS 애플리케이션과 통합된다. 오라클 클라우드 펑션은 오픈소스 Fn 프로젝트를 기반으로 하므로 개발자는 다른 클라우드 및 온프레미스 환경에 이식 가능한 애플리케이션을 만들 수 있다. 오라클 클라우드 펑션은 파이썬, 고, 자바, 루비, Node.js로 된 코드를 지원한다. 
 



X