컴맹 : 진화의 시작

지난번 글( 서버리스 Cloud Functions 사용하기 ) 에서 Cloud Functions 의 전반적인 내용에 대해서 훑어보았다. 작은 모듈 단위의 프로그램을 서버 구동 없이( 엄밀하게는 사용자가 신경 쓸 필요 없는 / 신경 쓸 수 없는 ) 사용할 수 있는 서버리스의 장점에 대해서 이야기를 했었는데 이번에는 그 한계에 대해 잠시 살펴보고 비판해보도록 하자. 이렇게 비판하는 정보를 공유하는 이유는 한계를 모르는 상태로 ..

이번에는 Cloud Functions 에 대해서 살펴보는 시간을 갖도록 한다. 기능은 단어 그대로 클라우드 위에 함수를 등록하고 트리거 ( Trigger )를 걸고 사용하는 개념이 되겠다. 쉽게 이야기해서 이벤트가 발생되면 등록해놓은 함수가 동작하는 방식이겠다. 이제 더 이상 작은 모듈을 위해 GCE 를 운영할 필요가 없겠다. Cloud Functions 은 서버리스로 동작하니까. AWS 에서는 Lambda 가 같은 개념이 되겠다. 아무튼,..

람다, 서버리스의 첫걸음을 통해 AWS 의 Lambda 서비스에 대해 간략하게 소개를 했다. 이번에는 조금은 더 심도 있는 이야기를 할 텐데 람다의 구조와 원리를 파악하고 자연스럽게 그 한계를 깨우치도록 하자. 내부 로직을 어느정도 이해하고 있어야 어떤 상황에 서버리스( Serverless ) 람다가 독이 되는지 알 수 있게된다. 어설프게 이해하고 사용 하다가는 독이 된다는 사실로 시작해보자.서버리스는 없다람다는 AWS 에서 서버리스를 대표..

아주 오래전부터 있던 개념이지만 클라우드와 함께 MSA 가 뜨거워지자 그 다음 단계로 Serverless 가 등장했다. Rest API 처리나 어차피 평소에 할일없이 빈둥거리는 서버를 없애고 인스턴스 내부에서 소소한 역할을 수행하던 것들을 함수처럼 클라우드에 등록해놓고 필요할 때 적절한 이벤트 트리거를 걸어 사용하는 방식이 람다에 대한 짧지 않은 소개가 되겠다. AWS lambda 는 GCP 에서는 Cloud Function 이라는 이름으로 존재하는..