2011년 5월 베니스에서 개최된 소프트웨어 아키텍처의 워크숍에서 "마이크로서비스"(microservice)라는 용어를 사용하여 참여자들이 공통의 아키텍처 스타일을 본 바, 즉 참여자 중 다수가 최근 탐구했던 바를 기술하였다. 2012년 5월, 동일 그룹은 "마이크로서비스"를 가장 적절한 이름으로 결정하였다 제임스 루이스는 2012년 3월 33rd Degree in Kraków in Microservices - Java, the Unix Way에서 사례 연구로서 이 아이디어 가운데 일부를 발표했는데, 이는 프레드 조지가 거의 같은 시기에 했던 내용과 같다. "섬세한 SOA"(fine grained SOA)으로서 이러한 접근을 설명한 넷플릭스의 에이드리언 콕크로프트는 웹 규모로 이 스타일을 개척했는데, 다른 사람들 다수(Joe Walnes, Dan North, Evan Bottcher, Graham Tackley)가 이 문서에서 언급한 바와 동일하다.

작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크

독립적으로 배포 가능하고, 다른 기술 스택(언어, DB 등)이 사용 가능한 단일 사업 영역에 초점

Monolithic Architecture는 SW 모든 요소가 한 프로젝트에 통합되어 있는 형태. 예로 모듈별로 개발하고, 하나의 결과물로 패키징하여 배포하는 형태. 웹의 경우 WAR 파일로 빌드

일정 규모 이상의 서비스에서는 한계

. 부분 장애가 전체 서비스의 장애로 확대

. Scale-out(나누어 일을 처리하는 방식)이 어려움

. 서비스 변경이 어렵고, 수정 시 장애의 영향도 파익이 힘듦

. 배포 시간이 오래 걸림 (최근 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세. 작은 변경에도 높은 수준의 테트스 비용이 발생

. 한 Framework와 언어에 종속 (Spring framework를 사용할 경우, blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적으로 강세, 자바를 이용하여 해당 모듈을 작성할 수 밖에 없음)

MSA는 API를 통해서만 상호작용. 서비스의 end-point를 API 형태로 노출하고, 세부 사항은 추상화. 내부의 구현로직, 아키텍처와 프로그래밍 언어, DB, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 가려짐

SOA의 특징을 다수 공통으로 가짐