소프트웨어 공학 수업을 듣는중에 모노리식 앱과 마이크로서비스에 대한 수업 설명이 있었다. Docker compose를 설명하고 이의 장점을 뒷받침 하기 위한 필요한 추가 전문 지식인 것 같다. 처음 들어보는 용어이고, 아직 잘 모르기때문에 정리해보려고 한다.
Monolithic App
Monolithic app은 모든 기능이 단일 프로그램 안에 구현된다.
애플리케이션 내부를 보자면, 구조체는 모놀리식이 아닐수도 있지만 여러 라이브러리, 구성 요소, 또는 레이어(애플리케이션 레이어, 도메인 레이어, 데이터 액세스 레이어 등)로 구성될 수 있다. 외부적으로는 단일 프로세스, 단일 웹 애플리케이션 또는 단일 서비스 같은 단일 컨테이너이다.
모놀리식 앱은 모든 기능 또는 대부분의 기능이 단일 프로세스 또는 컨테이너 내부에 있으며 이러한 기능은 내부레이어 또는 라이브러리에 구성 요소화된다. 이 방식의 단점은 애플리케이션의 규모가 커지면 그에 맞게 확장해야 한다는 것이다.
또한 '모든 것을 확장'하는 문제 외에도, 한 구성 요소를 변경하려면 전체 애플리케이션을 모두 다시 테스트하고 모든 인스터스를 다시 배포해야 한다.
이 내용을 정리하자면 비대한 app, 일부가 update되어도 전체 app이 re-deploy되어야하고ㅡ bug가 전체 app에 영향을 미치기 때문에 새로운 기술을 채택하기에 장벽이 있다. 그럼에도 불구하고 monolithic app은 일반적인 방법이고 많은 조직에서 이 아키텍처 방법으로 제품을 개발한다. 좋은 결과를 얻는 곳도 있고, 한계에 부딪히는 곳도 있다.
Microservices architecture
거의 모든 응용, 특히 Web 기반 app(front end + backend services including DB, login, search service, mail, etc.)
마이크로서비스란 소프트웨어를 구축하기 위한 아키텍처이자 하나의 접근 방식으로, 애플리케이션을 상호 독립적인 최소 구성요소로 분할한다. 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀리식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 연동되어 동일한 task를 완수한다. 소프트웨어 개발에 대한 이러한 접근 방식은 세분화, 경량화되어 있으며 다수의 애플리케이션 간에 유사한 프로세스를 공유하는 기능을 중시한다.
정리하자면 각 단일 서비스가 서로 loosely coupled되어있고 마이크로서비스들 사이에서 communication은 프로그램 속에서 arg를 전달하는 대신에 HTTP 통신 프로토콜 등을 통한 데이터교환이 REST API 즉 JSON 파일 형식으로 통신한다. 그러므로 각 service들은 bug 관점에서 모놀리식에 비교적 상호 독립적이다. 획기적이며 서로 다른 기술로 구현되어 monolithic의 단점을 장점으로 가진다.
