- 단일 백엔드에서 마이크로서비스 아키텍처로 전환하는 비용과 이점에 대한 기사
- 단일 코드베이스에 기여하는 팀의 수가 증가함에 따라 컴포넌트가 점점 더 연결되어 생산성이 감소하고 복잡성이 증가
- 이러한 문제를 완화하는 한 가지 해결책은 단일 백엔드를 API를 통해 통신하는 독립적으로 배포 가능한 서비스 세트, 즉 마이크로서비스로 분할하는 것
- '마이크로'라는 용어는 서비스에 대해 '마이크로'일 필요가 없으므로 오해의 소지가 있음. 더 적절한 용어는 서비스 지향 아키텍처
- 백엔드를 잘 정의된 경계를 가진 서비스 세트로 분해하면 각 서비스를 개발하고 운영하는 데 작은 팀 하나면 충분하므로 애플리케이션의 개발 속도가 증가
- 각 마이크로서비스는 독립적으로 확장되고 자체 필요에 따라 다른 기술 스택을 채택할 수 있어 새로운 기술의 실험과 평가가 용이
- 그러나, 마이크로서비스 아키텍처는 전체 시스템에 더 많은 움직이는 부분을 추가하여 복잡성을 증가시키고 일정한 표준화를 필요로 함
- 각 마이크로서비스에 대해 다른 언어, 라이브러리, 데이터스토어를 사용하면 애플리케이션을 유지 관리하기 어려운 혼란스러움으로 변환하여 개발자가 팀 간에 이동하는 것이 어려워짐
- 독립적인 서비스의 대규모 지원을 위해 새로운 서버, 데이터 스토어, 그 외의 자원을 쉽게 생성할 수 있어야 하며, 이는 상당한 자동화를 필요로 함
- 원격 호출은 비용이 많이 들고 시스템이 실패할 수 있는 새로운 방법을 도입하므로, 타임아웃, 재시도, 회로 차단기와 같은 방어 메커니즘이 필요
- 지속적인 통합은 코드 변경이 자동 빌드 및 테스트 프로세스를 거친 후 메인 브랜치에 병합되도록 보장
- 모든 마이크로서비스의 통합 테스트는 단일체 테스트보다 훨씬 어려움, 개별 서비스가 서로 상호 작용할 때 매우 미묘하고 예기치 않은 동작이 나타날 수 있음
- 서비스를 개발하는 팀은 일반적으로 그것에 대한 호출도 담당, 개발 작업과 운영 비용 사이에 마찰을 일으킴
- 마이크로서비스로 시스템 실패를 디버깅하는 것이 더 어려워짐, 모든 수준에서 좋은 로깅과 모니터링이 중요
- 애플리케이션을 별도의 서비스로 분할하면 데이터 모델이 더 이상 단일 데이터 스토어에 존재하지 않게 되어, 대개 최종 일관성을 받아들여야 함
- 일반적으로 단일체로 시작하고 서비스 간의 경계를 정확하게 설정하는 것이 어려운 경우에만 분할하는 것이 가장 좋음
- 마이크로서비스 우선 접근법으로 시작하는 것은 이미 그것에 대한 경험이 있고 그것을 위한 플랫폼을 구축했거나 하나를 구축하는 데 걸리는 시간을 고려한 경우에만 해야 함