서비스 지향 '아키텍처'와 마이크로 서비스 '아키텍처'는 최근에 큰 인기를 끌고 있다. 그 이유는

• 서비스를 사용하면 상호 결합이 철저하게 분리. 일부만 맞는 말
• 서비스를 사용하면 개발과 배포 독립성을 지원. 일부만 맞는 말

서비스 아키텍처?

• 시스템의 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의

• 모든 서비스가 반드시 아키텍처 관점에서 중요해야만 한다는 뜻 X

• 기능을 프로세스나 플랫폼에 독립적이 되게끔 서비스들을 생성하면 의존성 규칙 준수 여부와 상관 없이 큰 도움

  → 서비스 그 자체로는 아키텍처를 정의하지 않는다

• 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다

서비스의 이점?

결합 분리의 오류

• 시스템을 서비스들로 분리함으로 써 서비스 사이의 결합이 확실히 분리
• 하지만 프로세서 내의 또는 네트워크 상의 공유 자원 때문에 결합될 가능성이 여전히 존재
• 인터페이스가 잘 정의되어 있어야 한다는 이점에 대해서라면 이는 명핵한 사실이지만 서비스 인터페이스가 함수 인터페이스보다 더 엄격하고 정의되어있는 것은 아님

개발 및 배포 독립성의 오류

• 서비스를 사용함에 따라서 전담팀이 서비스를 소유하고 운영한다는 점
• 전담팀에서 각 서비스를 작성하고, 유지보수하며, 운영하는 책임을 질 수 있고 이러한 개발 및 배포 독립성은 확장 가능한 것으로 간주된다
• 이러한 믿음에도 어느 정도 일리가 있지만, 극히 일부
  1. 대규모 엔터프라이즈 시스템은 모노리틱 시스템이나 컴포넌트 기반으로도 구축할 수 있다
  2. '결합 분리의 오류'에 따르면 서비스라고 해서 항상 독립적으로 개발하고 배포하며 운영 할 수 있는 것은 아니다

야옹이 문제

• 해당 도시에서 운영되는 많은 택시 업체를 알고 있고, 고객은 승차 요청을 할 수 있는 택시 통합 시스템
• 확장 가능한 시스템을 구축하고 싶었기에, 우리는 수많은 작은 마이크로 서비스를 기반으로 구축하기로 결정