팀 자율성 향상
자율 팀을 만들고 팀끼리 긴밀한 유대 관계를 구축하고, 관료 절차에 얽매이지 않고 협업함으로써, 그렇지 않은 조직에 비해 더 효과적으로 성장하고 확장해왔다. 자율적 팀이 제대로 작동한다면, 팀 자율성은 구성원에게 힘을 실어주고 성장시키며, 더 빠른 업무 처리를 돕는다. 팀이 마이크로서비스를 소유하고 해당 서비스를 완전히 제어할 수 있으면, 더 큰 조직 내에서 발휘할 수 있는 자율성 범위 또한 증가한다.
대안은 없을까?
자율성(책임 분배)는 여러 방식으로 풀어낼 수 있다. 더 많은 책임을 팀에 부여하겠다고 아키텍처를 전환할 필요까진 없다. 그러나 본질적으로 자율성이란 팀에 어떤 책임을 부여할 수 있는지 파악하는 과정이며 여러 방식으로 풀어낼 수 있다. 코드 기반의 일부에 대한 소유권을 다른 팀에 부여하는 것은 하나의 해답이 될 수 있다. 이는 또한 기능적 배경에서 코드 기반의 일부를 결정할 권한이 있는 사람들을 식별함으로써 수행될 수 있다. 예를 들면 다음과 같다. 디스플레이 광고를 가장 잘 아는 라이언이 이에 대한 책임을 진다. 제인은 쿼리 성능 조율을 가장 잘 알기 때문에 해당 분에에 제인을 제일 먼저 투입해야 한다.
자율성(책임 분배)이 향상되면, 남이 도와줄 때까지 기다릴 필요가 없다. 그래서 해당 작업을 담당한 사람은 자유롭게 담당한 일을 하면 된다. 마이크로서비스 아키텍처로 전환할 필요 없이 자율성, 즉 해당 작업을 잘하는 사람이나 담당할 사람에게 맡기고 프로젝트를 진행하는 식으로 해도 된다.
시장 출시 시간 단축
개별 마이크로서비스에 대해 변경하고, 조정된 릴리스를 기다릴 필요 없이 이러한 변경사항을 배포함으로써, 고객에게 더 신속하게 기능을 제공할 수 있게 된다.
대안은 없을까?
소프트웨어를 더 빨리 출시하는 방법을 고려할 때 작용하는 변수는 매우 많다. 이 때 제작 경로 모델링 연습을 해보면 좋다. 이 과정에서 더 빠른 출시를 막는 변수가 생각하는 바와 많이 다르다는 사실을 깨우치기도 하기 때문이다. 소프트웨어 출시와 관련된 모든 단계를 검토하고 더 빠른 출시를 막는 변수를 파악해서 해결하면 마이크로서비스 아키텍처로로 전환활 필요 없이 출시 시간을 단축할 수도 있다.
부하를 다루기 위한 비용 효율적인 확장
프로세스는 개별 마이크로서비스로 분리해서 독립적으로 확장할 수 있다. 이는 비용 효율적으로 확장할 수 있다는 의미이기도 하다. 지금 당장은 부하를 다루는 과정에서 병목으로 작용하는 프로세스 부분에만 초점을 맞춰 확장할 필요가 있다. 또한 그러고 나서 부하가 적은 마이크로서비스는 축호할 수 있으며, 심지어 필요하지 않을 때는 서비스를 꺼도 무방하다. SaaS 제품을 구축하는 많은 회사가 마이크로서비스를 채택해 운영 비용을 더욱 효과적으로 통제할 수 있는 이유이다.
대안은 없을까?
수많은 대안이 있으며, 대부분은 마이크로서비스 지향 접근 방식보다 실험하기 쉽다. 시작 과정에서 성능이 더 좋은 컴퓨터를 확보할 수 있으며, 퍼블릭 클라우드 또는 다른 유형의 가상화 플랫폼을 사용하는 경우 간단히 더 큰 자원을 프로비저닝해 여기서 프로세스를 실행할 수 있다. 이와 같은 수직 확장은 분명히 한계가 있지만, 빠른 단기 개선을 추구한다면 무조건적으로 수직 확장을 무시해선 안 된다.
기본적으로 여러 사본을 실행하는 기존 모놀리스의 전통적인 수평 확장이 효과가 더 뛰어나다는 사실을 쉽게 증명할 수 있다. 로드 밸런서 또는 큐와 같은 부하 분배 메커니즘 뒤에 모놀리스의 여러 사본을 실행하면 더 많은 부하를 간단하게 처리할 수 있지만 사용하는 기술에 따라 병목 현상이 데이터베이스에 있는 경우에는 이런 확장 메커니즘은 도움이 안될 수도 있다. 시도하기 쉬운 방식인 수평 확장은 마이크로서비스를 고려하기에 앞서 적합성을 신속하게 평가할 수 있으며, 완전한 마이크로서비스 아키텍처보다 단점도 훨씬 더 적기 때문에 시도해봐야 한다.
견고성 향상
마이크로서비스를 사용하면 기능이 분해되기 때문에 더욱 견고한 아키텍처를 구현할 수 있다. 즉 기능의 한 영역에 미치는 영향으로 인해 전체 시스템으 중단할 필요가 없다. 또한 견고성을 가장 많이 요구하는 애플리케이션의 특정 부분에 시간과 에너지를 집중함으로써 시스템의 중요한 부분이 계속 작동하게 만들 수 있다. 여기서 중요한 고려사항은 마이크로서비스가 견고성을 무상으로 제공하지 않는다는 사실이다. 그보다는 네트워크 분할, 서비스 중단 등을 더 잘 견딜 수 있는 방식으로, 시스템을 설계할 수 있는 기회를 열어 놓는다. 여러 개별 프로세스와 개별 컴퓨터에 기능을 분산시키는 것만으로는 견고성 향상을 보장할 수 없다. 반대로, 장애가 발생하는 지점만 늘어날 뿐이다.
대안은 없을까?
아마도 로드 밸런서 또는 큐 같은 부하 분배 메커니즘 뒤에 모놀리스의 여러 사본을 실행하는 방식으로 시스템에 중복성을 추가한다. 또한 모놀리스 인스턴스를 여러 장애 평면에 분산시켜(예를 들면 모든 서버를 동일 랙 또는 동일 데이터 센터에 배치하지 않는 등) 애플리케이션의 견고성을 더욱 향상시킬 수 있다.
좀 더 안정적인 하드웨어와 소프트웨어에 대해 투자한다면, 현존하는 시스템 중단 원인을 철저히 조사하는 것만큼의 이익을 거둘 수 있다.
개발자 수 늘리기
작업 자체가 상호작용이 제한된 별도 작업으로 분할될 수 있는 경우에만 더 많은 인력을 충원하면 배포 속도도 인원 수에 비례해 계속해서 개선될 것이라고 한다. 경계를 명확하게 긋고 마이크로서비스가 상호 결합도를 제한하게 초점을 맞춘 아키텍처를 통해 우리는 독립적으로 작업 가능한 코드를 만들어낸다. 따라서 배포 경합을 줄임으로써 개발자 수를 늘리기를 원한다.
문제에 집중하는 개발자 수를 성공적으로 늘리려면, 팀 간에 상당한 수준의 자율성이 필요하다. 단순히 마이크로서비스만으로는 충분하지 않을 수 있다. 팀을 서비스 소유권에 맞춰 어떻게 정돈할지, 그리고 팀 간에 어떤 조정이 필요한지 생각해야 한다. 또한 작업을 제대로 분할함으로써, 수많은 서비스 사이에서 변경사항 조정이 필요하지 않게 만들어야 한다.
대안은 없을까?
마이크로서비스는 그 자체로 독립적으로 작업할 수 있는, 결합도가 약한 기능의 조각이므로 규모가 더 큰 팀에 적합하다. 대안으로 모듈식 모놀리스 구현을 고려할 수도 있다. 즉 다양한 팀이 각각 모듈을 소유하고 다른 모듈과 연동하는 인터페이스가 안정적으로 유지되기만 한다면, 격리된 상태에서 계속 자신의 모듈을 변경할 수 있다.
그러나 이 방법은 다소 제한적이다. 여전히 여러 팀 간에 경합이 발생한다. 아직 소프트웨어는 하나로 묶여서 배포되기 때문에 여러 이해당사자 사이에 조율이 필요하다.
신기술 수용
모놀리스는 일반적으로 기술 선택을 제한한다. 통상적으로 백엔드에는 하나의 프로그래밍 관례를 사용하는 하나의 프로그래밍 언어만 적용된다. 또한 배포 플랫폼도 하나, 운영체제도 하나, 데이터베이스 유형도 하나만 쓰게 고정되어 있다. 그러나 마이크로서비스 아키텍처를 사용하면 각 서비스마다 선택지가 다양해질 수 있다.
서비스 경계에서 기술 변화를 분리함으로써 우리는 격리된 상태에서 새로운 기술의 장점을 이해할 수 있고, 이런 기술이 문제로 판명될 경우에 미치는 영향을 제한할 수 있다.
신기술을 안전한 방법으로 시도할 수 있는 유연성을 통해 조직은 경쟁 우위를 점할 수 있다.
대안은 없을까?
소프트웨어를 단일 프로세스로 계속 출시하는 경우, 도입 가능한 기술에는 제한이 있다. 물론 동일한 실행 환경에서도 새로운 언어를 안전하게 채택할 수 있다. 예를 들어 JVM은 동일한 실행 프로세스 내부에서 여러 언어로 작성된 코드를 적절히 호스팅할 수 있다. 그러나 새로운 유형의 데이터베이스는 더욱 문제가 되는데, 점진적인 마이그레이션을 가능하게 만들기 위해 이전의 모놀리스 데이터 모델을 분해하기 때문에 새로운 데이터베이스 기술로 완전하고 즉각적으로 전환하지 않는 이상, 복잡하고 위험하다. 현재 기술 스택이 수명 종료로 간주되는 기술인 경우, 제대로 지원되는 최신 기술 스택으로 교체하는 방법 이외에는 다른 선택지가 없을지도 모른다.
