| 주섬주섬

서버리스는 백엔드에 코드가 저장될 공간이 필요하기 때문에 서버가 없다는 뜻이 아니다.

직접 서버를 관리하지 않는다라는 뜻이다.( BACKEND WHTHOUT SERVER MGMT ) => SERVERLESS

서버리스 서비스 : AWS Lambda, Google Cloud Functions, Apex, Terraform

서버가 바뀌어온 과정

Local Server ( HW/SW )

직접 서버를 설치하여 필요에 따라 서버를 설정하여 사용하였다.
- 장점
  - 필요에 따라 서버를 설정할 수 있다.
- 단점
  - 웹 사이트의 트래픽이 증가하면 메모리를 사와서 서버에 꽂아야한다.
  - 정전이 나면 서버가 죽는다
CLOUD Service ( SW )

대기업(아마존, 구글 등)의 최신식 서버를 빌려서 사용하는 방식으로 바뀌었다.
- 장점
  - 서버 증축/축소 시 서비스 요청으로 간단하게 가능하다.
  - 물리적인 공간(서버실)이 필요없다.
- 단점
  - 서버 비용이 추가적으로 발생한다.
Serverless

서버의 하드웨어뿐만 아니라 소프트웨어도 맡기고 사용자는 백엔드를 작은 함수단으로 쪼개서 올린다.
- 장점
  - 서버를 24시간 구동할 필요가 없고 리퀘스트가 오면 함수를 깨워서 사용한다. 그래서 저렴하다.
    
    서버리스가 아닌경우 서버는 24시간 돌아가고 있고 언제나 요청에 응답할 준비가 되어있다.
    
    서버리스는 업로드한 함수가 잠을 자고 있고 리퀘스트가 오는 순간 AWS는 함수를 깨우고 요청한 작업을 수행하고 다시 함수는 잠에 든다. 즉, 24시간동안 깨어서 대기안해도 된다. 덕분에 엄청 저렴해졌다.
    
    이전의 경우 유저가 0명이든 100명이든 같은 돈을 내야했지만, 서버리스에서는 수행한 함수만큼의 돈을 내면된다. 리퀘스트가 와서 함수를 뭔가 수행하면 돈을 내면 된다. 1백만개의 함수 수행을 20센트면 할 수 있다.
    
    덕분에 스케일 조정을 더 잘할 수 있다. 갑자기 유저 수가 천명으로 늘어나도 문제가 없다.
    
    AWS는 같은 함수의 복사본을 천개 만들어서 수행해버리고 유저들이 사라지면 다시 잠에 들게 된다.
    
    퍼포먼스도 영향을 받지 않는다. 유저가 많이 생기면 더 많은 함수를 복제하여 문제가 없다.

단점
- cold start : 서버가 응답하는 시간이 걸릴 수 있다.
  
  리퀘스트가 와서 함수를 깨우는데 아무래도 시간이 걸리기 마련이다.
  
  긴 시간은 아니겠지만 어찌되었든 시간이 걸린다.
  
  보통 서버는 항시 대기하고 있으니까 이런 문제가 없다.
  
  이러한 작은 시간차도 허용되지 않는 경우에는 서버리스는 좋은 선택이 아닐 수도 있다.
  
  AWS lambda의 경우 어떤 함수가 자주 쓰이는지 파악을 해서 해당 함수는 잠들지않고 리퀘스트에 빨리 대응할수 있도록 대기한다.
- 서버 제공자에 너무 의지하게 된다. 서버리스를 사용하기 위해 구조를 변경해줘야한다.
  
  서버리스 백엔드를 AWS에 배포했다면, 단순하게 함수를 빼서 다른곳으로 이사가기 어렵다.
  
  한 서버리스에서 다른쪽으로 마이그레이팅 하는것은 쉽지 않기 때문이다.
  
  AWS에서 서버를 빌렸다가 Google Cloud로 이사가는건 쉽다.
  
  하지만 서버리스에서 이사가는것은 간단한 내용이 아니다
  
  서버리스로 작업하면 어플리케이션의 구조 자체가 바뀌게 된다.

어떤 사람이 서버리스를 사용해야 하는가?

: 사이드프로젝트 , 최대한 빠르게 프로토타입을 출시하고 싶은 경우

서버리스로 작업하면 설정은 신경끄고 코드에만 집중하면 된다.

엄청 빠르고 쉽게 서버를 활용해서 제품을 내놓기 좋다.

서버 관리하고 설정하는데 시간을 아끼고 싶다.

서버리스는 백엔드를 하는 기존 방법을 대체하진 않겠지만 풀스택들이 제품을 빠르게 완료하는데 꽤나 매력적인 옵션이다.

출처

노마드 코더(Nomad Coders), 서버리스는 서버가 없는걸까? 8분 개념 설명! (2020. 01. 13)

SERVERLESS.COM