나중에 블로그 글 등의 형태로 자세히 밝혀 볼 예정이기는 한데 HTTP API 환경에 한정해서 간단하게 몇가지만 뽑아보자면
HTTP
Lambda: APIGateway 의 RPC 콜을 받아서 요청을 처리하는 로직 구현해야함
Cloud Run: 일반적인 HTTP 통신 / HTTP 기반 라이브러리나 프레임워크 그대로 활용가능
Concurrency
Lambda: 무조건 하나의 인스턴스는 한번에 하나의 요청만 처리 (한번에 100개의 요청이 들어오면 100개의 인스턴스가 실행되야함)
Cloud Run: 하나의 인스턴스는 사용자가 정한 한계선까지 동시에 처리 가능
부가설명: Cloud Run 이 Lambda 대비 시간당으로 보면 1.5배정도 비싸지만, 하나의 인스턴스가 100개의 Concurrency 를 허용한다면 1.5/100 정도로 저렴해짐
Cold / Warm / Hot
Lambda: Cold, Hot 말고 CPU 자원을 주지 않는 Warm 상태가 존재. APM 정보같은걸 보내기가 굉장히 힘들어짐 (APM 정보 보낼려고 응답속도가 늦어지면 보통 손해이니...) DB Connection 같은것도 Warm 상태에서 끊기던가 제대로 자원 해제가 안되서 DB Connection Pool 을 전부 소진해버리기도 함
Cloud Run: Cold 와 Hot 만 존재. 그럼에도 불구하고 AWS 로 치면 API Gateway 의 응답속도 만큼만 과금. 종료될때는 정상적인 자원 정리의 기회를 줌
개발환경
Lambda: 로컬에 개발환경 구축하기 굉장히 까다롭거나 언어 생태계 / CPU 아키텍처 제약이 굉장히 큼
Cloud Run: 일반 개발환경과 동일
이식성
Lambda: 람다용으로 짠 코드는 람다에 종속성을 가져서 다른 플랫폼으로 이식하기 어려움
Cloud Run: 코드수정 없이 Kubernetes 환경으로 이전 가능
나중에 블로그 글 등의 형태로 자세히 밝혀 볼 예정이기는 한데 HTTP API 환경에 한정해서 간단하게 몇가지만 뽑아보자면
HTTP
Lambda: APIGateway 의 RPC 콜을 받아서 요청을 처리하는 로직 구현해야함
Cloud Run: 일반적인 HTTP 통신 / HTTP 기반 라이브러리나 프레임워크 그대로 활용가능
Concurrency
Lambda: 무조건 하나의 인스턴스는 한번에 하나의 요청만 처리 (한번에 100개의 요청이 들어오면 100개의 인스턴스가 실행되야함)
Cloud Run: 하나의 인스턴스는 사용자가 정한 한계선까지 동시에 처리 가능
부가설명: Cloud Run 이 Lambda 대비 시간당으로 보면 1.5배정도 비싸지만, 하나의 인스턴스가 100개의 Concurrency 를 허용한다면 1.5/100 정도로 저렴해짐
Cold / Warm / Hot
Lambda: Cold, Hot 말고 CPU 자원을 주지 않는 Warm 상태가 존재. APM 정보같은걸 보내기가 굉장히 힘들어짐 (APM 정보 보낼려고 응답속도가 늦어지면 보통 손해이니...) DB Connection 같은것도 Warm 상태에서 끊기던가 제대로 자원 해제가 안되서 DB Connection Pool 을 전부 소진해버리기도 함
Cloud Run: Cold 와 Hot 만 존재. 그럼에도 불구하고 AWS 로 치면 API Gateway 의 응답속도 만큼만 과금. 종료될때는 정상적인 자원 정리의 기회를 줌
개발환경
Lambda: 로컬에 개발환경 구축하기 굉장히 까다롭거나 언어 생태계 / CPU 아키텍처 제약이 굉장히 큼
Cloud Run: 일반 개발환경과 동일
이식성
Lambda: 람다용으로 짠 코드는 람다에 종속성을 가져서 다른 플랫폼으로 이식하기 어려움
Cloud Run: 코드수정 없이 Kubernetes 환경으로 이전 가능
이거 말고도 많은데, 보통 공감하실만한 내용들만 몇개 뽑아봤습니다 ㅎㅎ