Micro service architecture
마이크로서비스는 현대적인 비즈니스 요건에 적합한 소프트웨어 개발에 대한 아키텍처 스타일 또는 접근 방법이다.
마이크로서비스는 갑자기 새로 발명된 것이 아니며, 기존 스타일에 진화한 것에 가깝다.
마이크로서비스는 서비스 지향 아키텍처(SOA)에 이어 점점 많은 인기를 끌고 있는 아키텍처 패턴으로, 데브옵스(DevOps)와 클라우드 진영에서 많은 각광을 받고 있다.
devOps : 소프트웨이 개발(Development)과 운영(Operations)의 합성어로, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 애자일성(agility) : 여러 의미가 있지만 함축적으로 말해 좋은 것을 빠르고 낭비 없이 만드는 것을 의미 하며, 예전에는 기민함으로 번역되기도 했지만 요즘에는 원어 그대로도 많이 사용된다. 전달(delivery) : 소프트웨어가 사용되는 곳에 소프트웨어를 전달, 납품, 인도하는 것을 의미한다.
 전통적인 개발과 마이크로서비스와 비교
대규모 애플리케이션 개발에 수년이란 긴 시간을 투자하던 시절은 지나갔다.
기업은 수년 전에는 처음부터 끝까지 비즈니스 기능 전체를 아우르는 통합 애플리케이션을 개발하는 데 관심을 기울였지만, 이제는 그렇지 않다.
 일체형 애플리케이션과 마이크로서비스 비교
마이크로서비스는 전통적인 일체형 애플리케이션에 비해 애자일성, 전달 신속성, 확장성 측면에서 나은 결과물을 만들어 낼 수 있다. 마이크로서비스는 빠르고 애자일한 애플리케이션을 개발하는 접근 방식을 사용해서 전체 소요 비용을 낮출 수 있다.
현대적인 아키텍처에는 시스템 일부분의 교체 가능성을 극대화하고, 교체에 소요되는 비용은 최소화 할 수 있는 능력이 있을 것이라고 기대한다. 마이크로서비스는 이런 기대에 부응할 수 있는 접근 방식이다.
마이크로서비스의 진화와 촉매 : 기술
html5와 css3 출현 및 모바일 애플리케이션의 발전으로 사용자 인터페이스의 위상도 바뀌었다. angular, ember, backbone등과 같은 클라이언트 측 자바스크립트 프레임워크는 반응형(responsive)및 적응형(adaptive)디자인에 힘입어 대단한 인기를 누리고 있다.
클라우드 도입이 대세가 됨에 따라 피보탈 클라우드 파운드리, 아마존 웹서비스, 세일즈포스, IBM 블루믹스, 레드햇, 오픈시스트 등과 같은 서비스로서의 플랫폼 (PasS) 벤더들의 등작은 미들웨어 컴포넌트를 만드는 방식에 변화를 가져왔다.
시스템 통합 부문의 큰 그림도 최근에 발전하고 있는 서비스로서의 통합 플랫폼(iPasS)기술에 의해 변화를 맞이하고 있다. 델의 부미, 인포메티카, 뮬소프트 등이 있다.
NoSQL과 NewSQL은 데이터베이스 영역의 혁신을 이끌고 있다.
몇 년 전만 하더라도 유명한 데이터베이스 제품은 손으로 꼽을 수 있을 많큼 많지 않고, 그마저도 모두 관계형 모델링을 기반으로 하는 제품들이었다.
하지만 오늘날에는 데이터베이스 종류가 엄청나게 많아졌다. 하둡, 카산드라, 카우치디비, 네오포제이, 뉴오디비 등이 있는데, 각각 아키텍처 관점에서의 특수한 문제를 해결하는데 특화돼 있다.
마이크로서비스란 무엇인가?
마이크로서비스는 많은 조직에서 고도의 애자일성, 전달 신속성, 확장성을 확보할 수 있는 중요한 수단으로 사용 중인 아키텍처 스타일이다. 마이크로서비스는 물리적으로 분리할 수 있는 모듈화된 애플리케이션을 만들 수 있는 방법을 제시한다.
마이크로서비스는 새롭게 별명된 것이 아니다. 넷플릭스, 아마존, 이베이 같은 조직에서는 분할 정복 기법을 이용해서 일체형 애플리케이션을 단일 기능을 수행하는 더 작은 크기의 원자화된 단위로 분할하는 데 성공했고, 그 덕분에 일체형 애플리케이션에서 겪어야 했던 많은 문제를 해결할 수 있었다.
마이크로서비스는 알리스타 콕번(Alistair Cockburn)이 2005년에 창안한 육각형 아키텍처(hexagonal architecture)에 사용된 아이디어에서 시작됐다. 육각형 아키텍처는 포트와 어댑터 패턴( Ports and Adapter pattern)으로도 알려져 있다.
마틴 파울러는 마이크로서비스를 다음과 같이 정의한다.
"마이크로서비스 아키텍처 스타일은 각자 별도의 프로세스에서 실행되며, HTTP자원 API와 같은 가벼운 매커니즘으로 통신하는 작은 서비스를 모아 하나의 애플리케이션을 만든다. 이런 작은 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화된 절차에 따라 독립적으로 배포 가능하다. 작은 서비스를 관리하는 데 중앙 집중형 관리 방식은 최소한으로 사용되며, 각 서비스는 서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용할 수도 있다."
마이크로서비스 사이의 통신이나 전송 방식에 대해 정해진 표준은 없다. 일반적으로 마이크로서비스는 HTTP와 REST 같은 경량 프로토콜을 주로 사용한다. 필요하다면 스리프트(Thrift), 제로엠큐(ZeroMQ), 프로토콜 버퍼(Protocol Buffers)나 아브로(Avro)처럼 특수한 목적에 최적화된 통신 프로토콜을 사용할 수도 있다.
마이크로서비스는 비즈니스 범위와 잘 들어맞는 경계를 갖고, 독립적으로 관리할 수 있는 라이프사이클을 갖고 있다는 사실 덕분에 데브옵스와 클라우드 기반의 서비스를 시작하는 기업들에게 이상적인 선택이 될 수 있다.
마이크로서비스 아키텍처는 벌집 모양과도 비교가 된다.
마이크로서비스의 원칙
서비스 하나에 책임도 하나.
SOLID 디자인 패턴 중 한 가지 원칙이기도 한 단일 책임 원칙은 하나의 단위 요소는 하나의 책임만 가져야 함을 의미한다.
클래스든 함수든 서비스든 간에 하나의 단위 요소는 반드시 하나의 책임만을 가져야 한다는 소리다. 어떤 상황에서든 두 개의 단위 요소가 하나의 책임을 공유해서는 안 되며, 하나의 단위 요소가 여러 개의 책임을 가져서도 안된다. 하나의 단위 요소가 여러 개의 책임을 가지면 결국 다른 요소들과 지나치게 높은 결합도를 형성하게 된다.
마이크로서비스는 자율적
마이크로서비스는 자기 완비적이고 독립적으로 배포할 수 있으며, 자율적인 서비스로서 비즈니스의 범위와 실행에 대해 전적인 책임을 진다.
마이크로서비스와 서비스 지향 아키텍처의 가장 큰 차이점 중 하나는 자율성 수준 차이다. 대부분의 서비스 지향 아키텍처 구현체가 서비스 수준의 추상화를 제공하는데 반해 마이크로시버스는 한발 더 나아가 실행 환경까지도 추상화 한다.
 전통적인 소프트웨어 와 마이크로서비스 비교
마이크로서비스의 특징
서비스는 일급 시민
마이크로서비스 세상에서는 서비스가 일급 시민이다. 마이크로서비스는 서비스 종단점을 API형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
마이크로서비스 안의 서비스의 특징.
- 서비스 계약
SOA와 비슷하게 마이크로서비스도 분명하게 정의된 서비스 계약에 의해 작성된다.
- 느슨한 결합
마이크로서비스는 독립적이고 서로 느슨하게 연결돼 있다. 대부분의 경우 마이크로서비스는 이벤트로 입력 받고 이벤트로 응답한다. 메시징, HTTP, REST가 마이크로서비스 사이에서 커뮤니케이션 수단으로 사용된다. 메시지 기반의 종단점은 결합도를 낮추는 고수준의 수단을 제공한다.
- 서비스 추상화
단순히 서비스의 구현 일체를 추상화 하는 것이라기 보다는 모든 라이브러리와 제반 환경 전체를 추상화한 것이다.
- 서비스 재사용
마이크로서비스는 덩어리째 재사용 가능한 서비스다.
- 무상태
제대로 설계된 마이크로서비스는 상태가 없으며, 서비스에 의해 관리되는 어떤 공유 상태와도 아무런 정보도 공유하지 않는다.
- 탐색 가능한(discoverable) 서비스
마이크로서비스는 탐색을 통해 찾을 수 있다. 일반적인 마이크로서비스는 자신의 존재를 스스로 드러내서 알리고, 탐색에 의해 찾아지고 사용될 수 있게 한다.
서비스가 중지되면 마이크로서비스는 자기 자신이 소속돼 있던 마이크로서비스 환경에서 스스로를 제거한다.
- 서비스 호환성(interoperability)
서비스는 표준 프로토콜과 메시지 교환 표준을 준수하기 때문에 호환성이 좋다. 전송 메커니즘으로는 메시징이나 HTTP 등과 같은 표준 방식을 사용한다. REST/JSON은 마이크로서비스 세상에서 호환성이 좋은 서비스를 개발하는 데 가장 널리 사용되는 방법이다. 커뮤니케이션 부분 최적화를 위해 프로토콜 버퍼, 쓰리프트, 아브로, 제로엠큐를 사용할 수 있지만 이런 비표준 프로토콜로 인해 서비스 전체적인 호환성은 제약 받을 수 있다.
- 서비스 조립성(composability)
마이크로서비스는 조립이 가능하다. 서비스의 조립성은 서비스 오케스트레이션 이나 서비스 연출을 통해 확보할 수 있다.
마이크로서비스는 가볍다
제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다.
그 결과 대부분의 마이크로서비스 구현체에서 볼 수 있는 공통적인 특징 중 하나는 마이크로서비스가 작은 공간만을 차지한다는 점이다.
다양한 언어로 구성할 수 있는 마이크로서비스
마이크로서비스는 자율적이고 모든 것을 추상화해 서비스 API 뒤에 숨기기 때문에 서로다른 마이크로서비스에서 서로 다른 아키텍처를 적용할 수 있다.
마이크로서비스 환경에서의 자동화
대부분의 마이크로서비스는 개발 과정에서부터 운영에 이르기까지 전 과정을 최대한으로 자동화 한다.
대규모의 기업 시스템 안에는 상당히 많은 수의 마이크로서비스 존재할 수 있다. 이렇게 많은 수의 마이크로서비스가 자동화되지 않는다면 관리 부담이 상당히 커질 수 있다.
더 작은 공간만을 필요로 하는 마이크로서비스의 특징 덕분에 개발에서 배포에 이르기까지의 과정을 상대적으로 쉽게 자동화할 수 있다.
- 개발 단계를 자동화를 위해 깃(git)같은 형상 관리 도구와 젠킨스(Jenkins), 트래비스CI 등과 같은 지속적 통합(CI, Continuous Integration) 도구를 함께 상ㅇ한다.
이런 자동화 과정에는 코드 품질 검사와 단위 테스트 자동화를 포함할 수도 있다.
-
테스트 단계에서는 셀레늄(Selenium), 큐컴버(Cucumber)나 다른 A/B 테스트를 적용할 수 있다. 마이크로서비스는 단위 비즈니스 영역에 맞춰 만들어지므로, 일체형 애플리케이션에서보다는 자동화해야 할 테스트 케이스의 수가 상대적으로 더 적다. 그래서 빌드할 때마다 회귀 테스트를 진행하는 것도 가능하다.
-
인프라스트럭처 프로비저닝(provisioning)도 도커와 같은 기술과 셰프(chef) 또는 퍼펫(Puppet)같은 릴리즈 관리 도구, 앤시블(Ansible)같은 구성 관리 도구를 함께 사용해서 자동화할 수 있다. 스프링 클라우드, 쿠버네티스(Kubernetes), 메소스(Mesos), 마라톤(Marathon)같은 도구를 사용하면 배포 자동화도 가능하다.
마이크로서비스를 지원하는 생태계
대부분의 대규모 마이크로서비스 구현체는 적재적소에 필요한 생태계(ecosystem)를 갖고 있다. 데브옵스 프로세스, 중앙 집중식 로그 관리, 서비스 레지스트리(service registry), API 게이트웨이, 광범위한 모니터링, 서비스 라우팅, 작업 흐름 통제 매커니즘 등이 마이크로서비스를 지원하는 생태계에 포함된다.
 cloud ecosystem
동적이고 분산돼 있는 마이크로서비스
성공적인 마이크로서비스 구현체들은 로직과 데이터를 서비스의 내부로 캡슐화한다.
-
데이터 및 로직의 분산
-
탈중앙화된 관리 체계
모든 로직과 데이터가 하나의 애플리케이션 경계 내에 존재하는 전통적인 애플리케이션과 비교해볼 때 마이크로서비스의 데이터와 로직은 분산돼 있다.
각 서비스는 특정 비즈니스 영역에 맞춰져 있고, 그 비즈니스 영역의 데이터와 로직만을 포함한다.
그리고 마이크로서비스 구현체들이 실행 환경에서 동적으로 레지스트리 정보를 구축하는 데 자동화 메커니즘을 사용하는 이유가 바로 여기에 있다.
붕괴 저항성, 빨리 실패하기, 자체 치유
붕괴 저항성(antifragility)은 넷플릭스에서 시험 적용해보고 성공을 거둔 기법이다. 붕괴 저항성은 현대적인 소프트웨어 개발 과정에서 든든한 안전장치가 포함된 시스템을 만들 수 있게 해주는 가장 강력한 접근 방식 중 하나다.
붕괴 저항성 개념은 나심 니콜라스 탈레프(Nassim Nicholas Taleb)가 그의 저서 '안티프래질: 불확실성과 충격을 성장으로 이끄는 ' 에서 소개한 개념이다. 현실에서 소프트웨어 시스템은 언제나 도전에 직면한다. 붕괴 저항성이 적용된 소프트웨어 시스템은 이런 도전을 해쳐 나가면서 진화하고, 시간이 지남에 따라 이런 도전에 대해 강한 내성을 갖게 된다.
아마존의 게임 데이(Game day) 실습이나 넷플릭스의 시미안 아미(Simian Army)는 이런 붕괴 저항성 실험의 대표적인 성공 사례라고 할 수 있다.
빨리 실패하기 (fail fast)는 장애를 견딜 수 있고 회복력이 좋은 시스템을 구축하는 데 사용되는 개념이다. 이런 철학은 절대로 장애가 발생하지 않는 시스템을 구축하기 보다는 장애를 예상하고 대응할 수 있는 시스템을 만드는 쪽에 더 무게를 둔다.
시스템이 얼마나 빨리 실패하는지. 또 실패할 경우 얼마나 빨리 정상 상태로 복구할 수 있는지가 정말 중요한 포인트다. 이런 접근 방식을 통해 관심의 초점은 평균 무고장 시간 (MTBF, Mean Time Between Failure)에서 평균 복구 시간 (Mean Time To Recovery)으로 이동한다.
빨리 실패하는 방식의 장점은 무엇인가 문제가 생겼을 때 스스로를 중지시키고, 문제가 더 이상 전파되지 않게 한다는 점이다.
자체 치유(self-healing)는 마이크로서비스에서 널리 사용되는 개념인데, 시스템이 장애로 부터 학습을 하고 스스로를 장애에 적응시킨다는 개념이다. 이런 시스템은 미래의 장애를 어느 정도 예방할 수 있다.
마이크로서비스의 장점
폴리글랏 아키텍처 지원
마이크로서비스는 자율적이고 독립적이므로 각 서비스는 자신만의 고유한 아키텍처와 여러 가지 버전의 기술을 적용해서 구축하고 운영할 수 있다.
실험과 혁신 유도
현대적인 아키텍처는 빠른 성공에 초점을 두고 번창하고 있다. 마이크로서비스는 다양한 실험을 시도햅고 빨리 실패하는 방식을 통해 기업들이 파괴적인 혁신을 이끌어 낼 수 있게 해주는 효과적인 수단 중 하나다.
마이크로서비스는 상당히 단순하고 크기가 작아 기업들은 큰 비용을 치루지 않고도 새로운 프로세스, 알고리즘, 비즈니스 로직 등을 여러 방식으로 실험해볼 수 있다.
애플리케이션에서 뭔가 새로운 것을 도입해보려고 하면 상당히 많은 돈이 필요하게 된다. 마이크로서비스 아키텍처에서는 특정 목표 기능을 수행할 수 있는 작은 마이크로서비스를 작성하는 것이 가능하고, 이런 마이크로서비스를 기존 시스템에 리액티브 스타일로 끼워 넣어 사용할 수 있다.
탄력적이고 선택적인 확장
마이크로서비스는 작은 단위의 작업이라서 필요한 서비스만을 선택해서 확장하는 선택적 확장과 서비스 품질(QoS : Quality of Service)을 구현할 수 있다.
확장에 대한 요구 사항은 애플리케이션 내의 기능에 따라 다른 수준으로 존재한다.
하지만 하나의 WAR나 EAR 파일로 패키징되는 일체형 애플리케이션에서는 전체 단위로만 확장 여부를 적용할 수밖에 없고, 모듈이나 서브시스템 단위로 확장 여부를 적용 할 수 없다.
마이크로서비스에서는 각각의 서비스를 개별적으로 확장하거나 축소할 수 있다. 선택적인 확장이 가능하기 때문에 마이크로서비스에서의 서비스 확장 비용은 상대적으로 적다.
스케일 큐브(Scale Cube)는 애플리케이션을 확장하는 데 필요한 세 가지 주요 접근 방식을 정의한다.
-
x 축 방향의 확장은 애플리케이션을 복제해서 수평적으로 확장하는 것을 의미
-
y 축 방향의 확장은 서로 다른 기능을 분리하는 것을 의미
-
z 축 방향의 확장은 데이터 파이셔닝(partitioning) 또는 샤딩(sharding)을 의미
y축 방향의 확장이 일체형 애플리케이션에 적용되면 일체형에 담겨있던 기능을 분리해서 비즈니스 기능에 맞게 더 작은 단위로 분리할 수 있다. 많은 조직에서 이 기법을 통해 일체형 애플리케이션에서 성공적으로 벗어날 수 있었다.
z축 방향의 확장은 전체 코드 베이스가 복제돼야 한다는 점에서 대단히 많은 비용을 필요로 하다.
대체 가능성
마이크로서비스는 자기 완비적이고 독립적으로 배포 가능한 모듈이기 땜ㄴ에 하나의 마이크로서비스를 비슷한 다른 마이크로서비스로 대체할 수 있다.
마이크로서비스는 자체 구축한 다른 마이크로서비스로 쉽게 대체할 수 있으며, 외부의 서드파티 업체가 확장해서 만든 다른 마이크로서비스로도 쉽게 대체할 수 있다.
제대로 설계된 마이크로서비스 시스템에서는 예약, 운임, 가격 산정에 서로 독립적인 마이크로서비스로서 존재한다. 지금은 외부의 서드파티가 만든 가격 산정 솔루션을 사용하고 있더라도 나중에는 다른 서드파티의 솔루션으로 교체하거나 자체적으로 만든 서비스로 교체할 수 있다.
유기적 시스템 구축 유도
마이크로서비스는 유기적인 시스템을 구축하는 데 현실적으로 많은 도움을 준다.
유기적인 시스템이란 시간이 지남에 따라 점점 더 많은 기능을 추가하면서 성장해가는 시스템을 말한다. 실제로 애플리케이션은 전체 라이프 사이클 동안 상상하지 못할 정도로 커지게 되고 유지 관리성이 급격하게 떨어지는 것이 대부분이다.
기술 부채 경감
마이크로서비스는 크기가 작고 최소한의 의존성만을 갖고 있기 때문에 시대에 뒤떨어져 수명이 다한 기술을 사용하는 서비스를 다른 기술을 쓰는 서비스로 최소한의 비용으로 전환할 수 있다.
기술 교체는 소프트웨어 개발 분야에 존재하는 커다란 장벽 중 하나다. 전통적인 많은 일체형 애플리케이션 개발에서는 기술의 급격한 변화로 인해 오늘 개발 중인 차세대 애플리케이션이 개발이 완료돼 운영에 들어가기도 전에 구식의 시스템이 돼 버리는 경우도 많다.
이를 잘 알고 있는 아키텍트와 개발자들은 여러 개의 추상화된 계층을 도입해서 기술 변화에 대처할 수 있는 대비책을 많이 만들어두려는 경향이 있다.
마이크로서비스는 전체 애플리케이션이 아니라 개별 서비스에 필요한 변경이나 기술 업그레이드가 가능하다.
예를 들어 EJB 1.1과 Hibernate로 작성된 500만 줄의 애플리케이션을 스프링, JPA, REST 서비스로 업그레이드 하는 것은 전체 애플리케이션을 새로 개발하는 것과 거의 비슷한 노력과 비용이 필요하다. 마이크로서비스에서는 이런 업그레이드를 통째로 진행하지 않고 점진적으로 진행할 수 있다.
다양한 버전의 공존
마이크로서비스는 서비스 자체뿐 아니라 서비스의 실행 환경도 함께 패키징하기 때문에 다양한 버전의 서비스가 동일한 환경에 함께 공존할 수 있다.
하나의 버전에서 다른 버전으로 전환할 때 서버를 중지시키지 않는 무중단 업그레이드가 이런 시나리오의 한 예인데, 무중단 업그레이드 시에는 일시적으로 두 개의 버전이 동시에 운영된다. 일체형 애플리케이션에서는 클러스터 내의 한 노드에서 새로운 서비스로 업그레이드 하는 일은 상당히 번거롭고, 클래스 로딩 이슈로 이어질 수 있기 때문에 이런 무중단 업그레이드는 대단히 복잡한 작업이 된다.
새 버전의 기능을 일부 사용자에게만 출시해서 먼저 사전 검증을 받을 수 있게 하는 카나리아 출시(canary release)도 다수 버전의 서비스가 공존하는 또 다른 사례다.
자기 조직화 시스템 구축 지원
마이크로서비스는 자기 조직화(self-organizing) 시스템을 만드는 데 도움이 된다. 자기 조직화 시스템을 지원함으로써 배포를 자동화할 수 있고, 회복력, 자기 치유력과 자기 학습 능력을 보유할 수 있다.
제대로 설계된 마이크로서비스 아키텍처에서 하나의 서비스는 다른 서비스에 대해 알지 못한다. 서비스는 큐에서 메시지를 받아 처리한다. 처리를 완료하면 메시지를 전송하고, 이 메시지는 다른 서비스에 전달돼 다른 처리가 시작된다. 따라서 전체 시스템에 대한 영향도 분석을 하지 않고도 기존 시스템 생태계에 어떤 서비스라도 쉽게 추가할 수 있다.
이벤트 주도 아키텍처 지원
마이크로서비스는 투명한 소프트웨어 시스템을 개발하는 데 도움을 준다. 전통적인 시스템은 고유 네이티브 프로토콜을 통해 의사소통하기 때문에 일종의 블랙박스 애플리케이션처럼 동작한다.
제대로 설계된 마이크로서비스 아키텍처는 언제나 입력 및 출력 이벤트를 사용해서 동작한다. 이런 이벤트는 어떤 서비스에서든 접근해서 연결될 수 있다. 일단 추출되기만 하면 이벤트는 아주 다양한 방식으로 사용 될 수 있다.
데브옵스 지원
마이크로서비스는 데브옵스를 가능하게 하는 주요 조력자 중 하나다. 데브옵스는 많은 기업에서 실제로 도입되고 있으며, 특히 전달 신속성과 애자일성을 높이는 데 중점을 둔다. 데브옵스를 성공적으로 도입하려면 아키텍처 측면에서의 변화뿐 아니라, 문화, 프로세스상에서의 변화가 필요하다. 데브옵스는 애자일 개발, 빠른 속도의 출시 주기, 자동화된 테스트, 자동화된 인프라스트럭처 프로비저닝, 자동화된 배포를 적극적으로 지지한다.
마이크로서비스는 모든 문제를 해결할 수 있는 궁극의 해답은 아니지만, 많은 데브옵스 구현체의 중심에 자리 잡고 있다. 많은 데브옵스 도구와 기술은 마이크로서비스를 사용하면서 진화하고 있다.
전체 빌드를 수행하는 데 몇 시간씩 걸리고, 애플리케이션을 시작하는 데 20~30분이 소요되는 일체형 애플리케이션을 생각해보자. 아마도 이런 애플리케이션은 이상적인 데브옵스 자동화로 보이지 않을 것이다. 그리고 거대한 일체형 애플리케이션은 자동화에 친화적이지 않기 때문에 지속적인 테스트와 배포도 대단히 어려운 일이 된다.
반대로 작은 규모의 마이크로서비스는 테스트 친화적이며, 위와 같은 데브옵스의 요구 사항을 더 쉽게 만족시킬 수 있다.
마이크로서비스는 더 작고 개발에 중점을 두는 애자일한 개발 팀 조직을 가능하게 된다. 그리고 마이크로서비스의 경계에 맞게 개발 팀을 조직할 수 있다.
저자