SOA(service-oriented architecture)는 서비스 인터페이스를 통해 소프트웨어 구성 요소의 재사용과 상호 운용성을 가능하게 하는 방법을 정의합니다. 서비스는 공통 인터페이스 표준과 아키텍처 패턴을 사용하므로 새로운 애플리케이션에 신속하게 통합될 수 있습니다. 이로써 애플리케이션 개발자는 기존의 기능을 재개발 또는 복제하거나 기존의 기능을 연결하거나 상호 운용성을 제공하는 방법을 알아야 했던 수고를 덜 수 있습니다.

SOA의 각 서비스는 완벽한 개별적 비즈니스 기능(예: 고객 신용 확인, 월별 융자 상환액 계산 또는 모기지 신청 처리)의 실행에 필요한 코드와 데이터를  구현합니다. 이러한 서비스 인터페이스는  서비스의 구현 방법을 거의 또는 전혀 모르더라도 호출이 가능하여 애플리케이션 간의 종속성을 줄여주는 느슨한 결합을 제공합니다. 

이 인터페이스는 서비스 제공자와 서비스 소비자 간의 서비스 계약입니다. 서비스 인터페이스를 뒷받침하는 애플리케이션은 Java, Microsoft .Net, Cobol 또는 공급업체(예: SAP)가 패키지형 소프트웨어 애플리케이션으로 공급하는 기타 프로그래밍 언어로 작성하거나 SaaS 애플리케이션(예: Salesforce CRM) 또는 오픈 소스 애플리케이션으로 제공되었습니다. 서비스 인터페이스는 xml(eXtensible Markup Language) 기반의 표준 태그 구조인 WSDL(Web Service Definition Language)을 사용하여 정의되는 경우가 많습니다.  

SOAP(Simple Object Access Protocol)/HTTP 또는 Restful HTTP(JSON/HTTP)와 같은 표준 네트워크 프로토콜을 사용하여 서비스를 노출하여 데이터를 읽거나 변경하기 위한 요청을 전송합니다. 서비스 거버넌스는 개발을 위한 라이프사이클을 제어하고, 적절한 단계에서 서비스는 개발자가 신속하게 이들을 찾아 재사용하여 새로운 애플리케이션 또는 비즈니스 프로세스를 구성할 수 있도록 하는 레지스트리에서 게시됩니다.

이러한 서비스는 처음부터 빌드할 수 있지만 서비스 인터페이스로 레코드의 레거시 시스템으로부터 기능을 노출하여 생성하는 경우가 많습니다.

이와 같이 SOA는 지난 수십 년 간의 애플리케이션 개발과 통합 과정의 발전에서 중요한 단계를 나타냅니다. 1990년대 후반에 SOA가 등장하기 전에는 애플리케이션을 다른 시스템에 있는 기능 또는 데이터에 연결하려면 복잡한 지점 간 통합, 즉 개발자들이 각각의 새로운 개발 프로젝트에 대해 부분적으로 또는 전체적으로 재작성해야 했던 통합이 필요했습니다. SOA에서 이러한 기능을 노출함으로써 개발자는 손쉽게 기존 기능을 재사용하고 SOA ESB 아키텍처를 통해 연결할 수 있게 되었습니다(아래 참조).

SOA와 최근의 마이크로서비스 아키텍처는 많은 단어를 공통으로 공유하지만(예: "서비스", "아키텍처") 나중에 설명하듯이 관련성이 적으며 실제로 다른 범위에서 작동합니다.

엔터프라이즈 서비스 버스(ESB)는 중앙 집중식 소프트웨어 구성요소가 애플리케이션 간의 통합을 수행하는 아키텍처 패턴입니다.  ESB는 데이터 모델을 변환하고, 연결성/메시징을 처리하고, 라우팅하며, 통신 프로토콜을 변환하며 잠재적으로 다중 요청의 구성을 관리합니다. 새로운 애플리케이션의 재사용을 위해 ESB는 이러한 통합과 변환을 서비스 인터페이스로 제공할 수 있습니다. 일반적으로 ESB 패턴은 최고의 생산성을 보장하는 특별히 설계된 통합 런타임과 툴 세트를 사용하여 구현됩니다.

ESB 없이 SOA를 구현할 수 있지만, 이는 단지 여러 개의 서비스가 있는 것이나 마찬가지입니다.  각 애플리케이션 소유자는 필요한 서비스에 직접 연결하여 각 서비스 인터페이스에 맞게 필요한 데이터 변환을 수행해야 합니다. 이는 (인터페이스를 재사용할 수 있더라도) 상당한 작업을 요하며 각 연결이 지점 간 지점이므로 향후 상당한 유지보수 문제가 발생합니다.  실제로 ESB는 사실상 SOA 구현의 요소로 간주되었기 때문에 두 용어는 종종 동의어로 사용되어 혼란을 일으킵니다.

ESB 자세히 보기

이전의 아키텍처와 비교하여, SOA는 기업에 상당한 이점을 제공했습니다.

• 비즈니스 민첩성 향상, 출시 시간 단축: 재사용 가능성이 핵심입니다.  재사용 가능한 서비스에서 애플리케이션을 조립하여 발생하는 효율성, 즉 새로운 개발 프로젝트마다 재작성 및 재통합을 수행하는 대신 빌딩 블록을 활용하여 달성할 수 있는 효율성 덕분에 개발자들은 새로운 비즈니스 기회에 대응하여 훨씬 더 신속하게 애플리케이션을 구축할 수 있습니다. 서비스 지향 아키텍처 접근 방법은 애플리케이션 통합, 데이터 통합 및 비즈니스 프로세스 또는 워크플로우의 서비스 오케스트레이션 스타일 자동화를 위한 시나리오를 지원합니다. 이를 통해 개발자는 통합에 드는 시간을 대폭 줄이고 애플리케이션 제공 및 향상에 집중하는 데 드는 시간을 대폭 늘릴 수 있으므로 소프트웨어 설계 및 소프트웨어 개발 속도가 빨라집니다. 
  
  
• 신규 시장에서 레거시 기능을 활용하는 능력: 잘 만들어진 SOA를 통해 개발자들은 하나의 컴퓨팅 플랫폼 또는 환경에서 '종속된' 기능을 쉽게 사용할 수 있으며 이를 신규 환경과 시장으로 확장할 수 있습니다. 예를 들어, 많은 회사에서는 SOA를 사용하여 메인프레임 기반 금융 시스템에서 새로운 웹 애플리케이션으로 기능을 노출함으로써 고객들이 이전에 회사의 직원이나 비즈니스 파트너와의 직접 상호 작용을 통해서만 액세스할 수 있었던 프로세스와 정보에 직접 접근할 수 있도록 합니다.
  
  
• 비즈니스와 IT 간의 협업 개선: SOA에서 서비스는 비즈니스 용어(예: '보험 견적 생성' 또는 '자본 설비 ROI 계산')로 정의될 수 있습니다. 이를 통해 비즈니스 분석가는 보다 나은 결과로 이어질 수 있는 중요 인사이트(예: 서비스를 사용하여 정의하는 비즈니스 프로세스의 범위 또는 프로세스 변경 시 비즈니스에 미치는 영향)를 활용하여 개발자와 보다 효과적으로 협력할 수 있습니다.

2010년 즈음, 사실상 모든 산업 분야의 선도적 기업들이 SOA 구현을 위해 전력을 기울이고 있었습니다. 예를 들면 다음과 같습니다.

• Delaware Electric에서는 SOA에 의존하여 이전에는 서로 소통하지 않았던 시스템을 통합했으며, 결과적으로 개발 효율성이 향상되어 5년간 주 정부에서 강제한 전기 요금 동결 중에도 기업이 지불 능력을 유지할 수 있었습니다.
  
  
• Cisco는 Cisco의 부서, 인수 회사 및 비즈니스 파트너가 웹 사이트에 통합할 수 있는 서비스로 주문 프로세스를 노출시켜 모든 제품과 채널에서 제품 주문 경험이 일관적인지 확인하기 위해 SOA를 채택했습니다.
  
  
• 필라델피아의 IBC(Independence Blue Cross)에서는 환자 데이터를 처리하는 다양한 구성 요소(IBC 고객 서비스 에이전트, 의사 진료실, IBC 웹 사이트 사용자)가 동일한 데이터 소스('단일 소스의 진실')를 사용하여 작업 중임을 확인할 수 있도록 SOA를 구현했습니다.

전문가들은 SOA와 마이크로서비스를 비교하고 상호 관계의 미묘함을 정의하는 수많은 문서와 디지털 페이지를 작성해왔습니다. 본문의 목적상, 둘 사이의 주된 차이점은 구성요소의 결합과 사용 범위입니다.

• SOA는 통합 아키텍처 스타일이며 전사적 개념입니다. SOA는 기존 애플리케이션이 느슨하게 결합된 인터페이스를 통해 노출되도록 합니다. 각 인터페이스는 확장된 엔터프라이즈의 한 부분에서 애플리케이션이 다른 애플리케이션의 기능을 재사용하도록 지원하는 비즈니스 기능에 대응됩니다.
  
  
• 마이크로서비스 아키텍처는 애플리케이션 아키텍처 스타일이며 애플리케이션 범위의 개념입니다. 이는 단일 애플리케이션의 내부를 독립적으로 변경, 스케일링 및 관리할 수 있는 작은 조각으로 분할할 수 있도록 합니다. 이는 애플리케이션 간의 소통 방식을 정의하지는 않습니다. SOA에서 제공한 서비스 인터페이스의 엔터프라이즈 범위로 되돌아가는 것이기 때문입니다.

마이크로서비스 아키텍처는 가상화, 클라우드 컴퓨팅, Agile 개발 사례 및 DevOps의 부상과 함께 등장하여 인기를 얻었습니다. 이러한 상황에서 마이크로서비스의 장점들은 대부분 컴포넌트의 디커플링으로부터 발생하며, 이는 다음을 간소화하고 개선합니다.

• 개발자 민첩성과 생산성: 마이크로서비스를 사용하면 개발자는 애플리케이션의 나머지 부분에 영향을 주지 않고도 애플리케이션의 일부에 신기술을 통합할 수 있습니다. 임의의 컴포넌트를 다른 컴포넌트와 독립적으로 수정, 테스트 및 배치할 수 있으며, 이는 반복 주기를 가속화합니다.
  
  
• 확장성: 마이크로서비스는 클라우드 확장성을 최대한 활용할 수 있습니다. 컴퓨팅 리소스의 가장 효율적인 사용과 워크로드 요구사항에 대한 가능한 가장 빠른 응답을 위해 임의의 컴포넌트를 기타 컴포넌트와 독립적으로 스케일링할 수 있습니다.
  
  
• 복원성: 다시 디커플링 덕분에 마이크로서비스 일부의 장애는 다른 마이크로서비스에 영향을 주지 않습니다. 그리고 각 마이크로서비스는 다른 컴포넌트나 전체 애플리케이션을 최대의 공통 가용성 요구 사항에 적용하지 않고도 자체 가용성 요구 사항을 수행할 수 있습니다.

SOA와 마이크로서비스의 차이점에 대한 자세한 설명은 "SOA 및 마이크로서비스: 차이점"을 참조하세요.

 마이크로서비스 아키텍처가 애플리케이션 설계에 대한 민첩성, 확장성 및 복원성을 개선할 수 있는 가능성이 있듯이 이러한 동일한 기술을 통합에 적용할 수도 있습니다. 이는 시간이 지나면서 과도하게 중앙 집중화된 ESB 패턴과 중앙 집중화된 관련 통합 전문가 팀이 병목 현상을 일으킬 수 있기 때문에 중요합니다.  마이크로서비스 원칙을 차용하여 우리는 잠재적으로 ESB를 더욱 세분화되고 분산된 통합으로 나눌 수 있습니다. 이는 애자일 통합을 뒷받침하는 핵심 전제 중 하나입니다.