1. PaaS는?

개발자들에게 필요한 것을 가능하게 플랫폼 서비스 제공

소프트웨어가 배포/전달되는 과정에서 장애를 최소하하여 가치 전달

2. PaaS의 등장이 만든 변화

• Heroku, Google App Engine 등 PaaS 등장 이후 대기업부터 스타트업까지 다양한 적용이 있었음
• PaaS의 등장으로 개발자들이 개발에 집중 할 수 있게 됨
• 프로덕션 환경에서 개발 뿐 아니라 배포/운영/장애대응 등 개발자의 워크플로 변화
• PaaS의 성숙으로 보안/효율화 등 다른 요소에 집중 가능

3. IaaS와의 비교

PaaS

• IaaS에 비해 사전 구성(Optionated)된 부분이 많음
• 풀스택 개발자의 역할에 적합 적절한 보안 구성에 유리

IaaS

• IaaS에서 AWS의 IAM과 같은 서비스는 너무 복잡하기 때문에 전체 보안 영역을 완벽하게 구성 하는 것에 리스크가 있을 수 있음 - 개발자가 적합한 IAM 구성 할 것을 기대하기 어려움
• 개발자가 책임져야 할 영역이 넓음: 아키텍처, 클라우드 네이티브 패턴, 고가용성 확보 등
• 보안/법령 준수 등의 영역을 다른 전문가와 역할 분할 필요

4. PaaS/IaaS/CaaS/MSA의 관계

PaaS에서의 MSA

• MSA 구성에 최적화 되어있음
• MSA의 부상은 PaaS의 등장과 무관하지 않음

IaaS와 PaaS

• GAE(Google App Engine)으로 시작한 GCP - 클라우드 네이티브에 적합한 서비스로 시작
• VMWare가 가상화로 새 시대를 열었다면, Amazon은 가상화된 인프라에 as a Service라는 개념을 덧붙여 게임체인저가 되었음

5. IaaS를 선호했던 개발자들

• Azure/GCP 등의 CSP는 PaaS로 서비스를 시작
• PaaS에 적합한 소프트웨어 디자인 패턴/아키텍처에 대한 이해가 준비되지 않았음
• Oracle DBMS를 사용하기 위해 업그레이드/마이그레이션 등이 필요: PaaS로의 전환 과정에서 소프트웨어를 그대로 활용하기 어려웠음
• IaaS가 프로덕션 환경에서 인프라가 안정적일 것으로 예측하기 쉬웠음

6. PaaS에서의 컨테이너/컨테이너 오케스트레이션

• 컨테이너/오케스트레이션과 PaaS는 분리해서 생각해야 함
  컨테이너: 컨테이너를 구동 시키기 위해 주변에 여러 제반 사항 필요
  PaaS: 컨테이너 기반
• 컨테이너는 모던 소프트웨어 디자인에서 필수불가결한 선결요건
• 쿠버네티스는 새로운 돌파구가 될 만한 기술, PaaS와 같이 어플리케이션 플랫폼 그 자체라기 보다 플랫폼을 구성하기 위한 플랫폼(Platform for building platforms, not an application platform itself)
• 쿠버네티스는 파드/PV/LBaaS 등 추상화된 인프라 영역을 다루고 구성
• PaaS는 인프라를 추상적 영역에 놔두고 사용자가 컨트롤 할 수 있게 함

7. Paas로의 전환을 위한 가이드라인

• Pain Point가 어디에 있는지 확인하는게 우선
• FaaS(Function as a Service)
  PaaS에서 선택 가능한 선택지
  사용한 컴퓨팅 리소스 만큼만 과금
  Event 기반의 어플리케이션에 적합
• PaaS
  Legacy 데스크탑 클라이언트 어플리케이션에 적합
  웹 어플리케이션 셋에 적합
• CaaS
  Infrastructure 구성에 Pain Point가 있을 때 적합
  Legacy 환경의 워크로드를 컨테이너 환경으로 그대로 이관하는 것은 추가적 보안 문제를 야기할 수 있음