ESB, 즉 엔터프라이즈 서비스 버스는 중앙 집중식 소프트웨어 컴포넌트가 애플리케이션 간의 통합을 수행하는 데 이용하는 아키텍처 패턴입니다. ESB는 데이터 모델을 변환하고, 연결을 처리하고, 메시지 라우팅을 수행하며, 통신 프로토콜을 변환합니다. 다중 요청의 구성을 관리하기도 합니다. ESB 덕분에 이러한 통합과 혁신이 새로운 애플리케이션에서 재사용 가능한 서비스 인터페이스의 형태로 제공될 수 있습니다.

일반적으로 ESB 패턴은 최고의 생산성을 보장하는 특별히 설계된 통합 런타임 및 툴 세트(즉, esb 제품)를 사용하여 구현합니다.

ESB는 SOA, 즉 서비스 지향 아키텍처의 필수 컴포넌트이며, 1990년대 후반에 등장한 소프트웨어 아키텍처입니다.SOA는 서비스 인터페이스를 통해 소프트웨어 컴포넌트를 재사용할 수 있는 방법을 정의합니다. 일반적으로 이 서비스에서는 표준 인터페이스(즉, 웹 서비스)를 사용하는데, 그러면 신규 애플리케이션의 서비스에서 수행하는 기능을 복제하지 않고도 신규 애플리케이션에 빠르게 통합될 수 있습니다.

SOA의 각 서비스는 완전한 개별 비즈니스 기능(예: 고객 신용 확인, 월별 융자 상환액 계산, 모기지 신청 처리)의 실행에 필요한 코드와 데이터를 구현합니다. 이러한 서비스 인터페이스는 느슨한 결합을 제공합니다. 즉, 서비스 구현 방법을 거의 또는 전혀 모르더라도 호출이 가능하므로, 애플리케이션 간 종속성이 줄어듭니다. 서비스 인터페이스를 뒷받침하는 애플리케이션은 Java, Microsoft .Net, Cobol 또는 기타 프로그래밍 언어로 작성할 수 있습니다. 그리고 벤더의 패키지형 엔터프라이즈 애플리케이션(예: SAP), SaaS 애플리케이션(예: Salesforce CRM)으로 공급되거나 오픈 소스 애플리케이션으로 제공될 수 있습니다.  

서비스 인터페이스는 xml(extensible markup language) 기반의 표준 태그 구조인 WSDL(Web Service Definition Language)을 사용하여 정의되는 경우가 많습니다.  SOAP(simple object access protocol)/HTTP 또는 JSON/HTTP와 같은 표준 네트워크 프로토콜을 사용하여 서비스를 노출함으로써 데이터 읽기 또는 변경 요청을 보냅니다. 서비스 거버넌스는 개발을 위한 라이프사이클을 제어합니다. 그리고 적절한 단계에 서비스가 레지스트리에 게시되는데, 그러면 개발자가 신속하게 서비스를 찾아내고 재사용하여 새로운 애플리케이션 또는 비즈니스 프로세스를 구성할 수 있습니다.

서비스는 완전히 새로 빌드될 수 있으나, 대개는 레거시 기록 시스템(SoR)에서 기능을 노출하는 방식으로 생성됩니다. 기업에서는 레거시 시스템의 전면에서 표준 기반 서비스를 제공하고, ESB를 사용하여 어댑터나 커넥터를 통해 직접 레거시 시스템에 연결하는 방식을 선택할 수 있습니다. 또는 애플리케이션에서 자체 API를 제공하기도 합니다. 어떤 경우이든 엔터프라이즈 서비스 버스는 신규 애플리케이션을 레거시 인터페이스로부터 격리합니다. ESB가 레거시 시스템 서비스에 연결하는 데 필요한 변환과 라우팅을 수행합니다.

ESB 아키텍처 없이 SOA를 구현할 수는 있으나, 그러면 수많은 서비스만 있는 것이나 마찬가지입니다. 각 애플리케이션 소유자는 필요한 서비스에 직접 연결하고, 각 서비스 인터페이스에 맞게 필요한 데이터 변환을 수행해야 합니다. 이는 (인터페이스를 재사용할 수 있더라도) 매우 수고스러운 작업이며, 각 연결이 점대점(point-to-point) 연결이므로 유지보수의 부담이 커집니다.

이론상 중앙 집중형 ESB는 엔터프라이즈 환경 전반에서 서비스 간 통신, 메시징, 통합을 표준화하고 획기적으로 간소화할 수 있습니다. 하드웨어 및 소프트웨어 비용은 분담할 수 있습니다. 즉, 전체 사용량을 기준으로 필요에 따라 서버를 프로비저닝하여 확장형 중앙 집중식 솔루션을 제공합니다.  전문가로 구성된 단일 팀에서 통합 개발 및 유지 관리를 맡을 수 있으며, 필요하다면 교육도 받습니다.

소프트웨어 애플리케이션이 ESB에 연결('통신')하면, ESB가 프로토콜 변환, 메시지 라우팅, 트랜잭션 실행을 위한 상호 운용성에 필요한 데이터 형식으로의 변환 등을 맡습니다. 이러한 엔터프라이즈 서비스 버스 아키텍처 접근법은 애플리케이션 통합, 데이터 통합, 비즈니스 프로세스의 서비스 오케스트레이션 스타일 자동화의 시나리오를 지원합니다.  그러면 개발자가 애플리케이션 통합에 보내는 시간을 대폭 줄이고 애플리케이션 제공 및 개선에 더 많은 시간을 투자할 수 있습니다. 이러한 통합을 한 프로젝트에서 다음 프로젝트로 재사용하는 것이 가능하므로, 다운스트림에서 더 큰 생산성 향상 및 비용 절감의 이점을 누릴 수 있습니다.

하지만 ESB가 많은 조직에서 성공적으로 배치되었음에도 ESB를 병목 지점으로 간주하는 곳도 많습니다. 통합을 변경하거나 개선하는 경우, 이 통합을 사용한 다른 사용자가 불안정해질 수 있습니다. ESB 미들웨어 업데이트가 기존 통합에 영향을 미치곤 했기 때문에 업데이트하려면 대규모의 테스트가 필요했습니다. ESB가 중앙에서 관리되었기 때문에 애플리케이션 팀은 각자의 통합을 위해 기다려야 하는 상황이 되었습니다. 통합의 규모가 늘어나면서 ESB 서버를 위한 고가용성 및 장애 복구 구현에 더 많은 비용이 들기 시작했습니다. 게다가 여러 기업이 참여하는 프로젝트의 형태로 진행되는 ESB는 자금 조달이 쉽지 않아 이러한 기술적 과제가 난관에 봉착했습니다.

결국 중앙 집중식 ESB를 유지, 업데이트, 확장하는 것이 매우 힘들어지고 비용 부담도 커지면서 ESB와 SOA의 본래 취지와 달리 생산성 향상의 이점을 제때 누리지 못하게 되었습니다. 진일보한 혁신을 기대했던 LoB(line of busienss) 팀은 실망할 수 밖에 없었습니다.

ESB의 상승과 하락의 역사가 궁금하다면 “ESB의 운명”을 읽어보세요.

마이크로서비스 아키텍처에서는 단일 애플리케이션의 내부를 작은 조각으로 나눌 수 있는데, 이 조각은 독자적인 변경, 확장, 관리가 가능합니다. 마이크로서비스는 가상화, 클라우드 컴퓨팅, 애자일(Agile) 개발 방법론, DevOps의 부상과 함께 등장하여 본격적으로 구현되기 시작했습니다. 이와 관련하여 마이크로서비스는 다음과 같은 이점을 제공합니다.

• 개발자의 민첩성과 생산성 향상 개발자가 애플리케이션의 다른 부분을 수정하거나 '업그레이드'하지 않고도 새로운 기술을 애플리케이션의 한 영역에 적용할 수 있습니다. 
• 더 간편하고, 경제적으로 확장 어떤 컴포넌트도 다른 컴포넌트에 독립적으로 확장할 수 있습니다. 그러면 워크로드 수요에 가장 빨리 응답하고 컴퓨팅 리소스를 가장 효율적으로 사용할 수 있습니다.
• 회복 탄력성 강화 어떤 컴포넌트에 오류가 발생하더라도 나머지 컴포넌트에 영향을 주지 않습니다. 그리고 각 마이크로서비스는 각자의 가용성 요구 사항에 따라 실행할 수 있습니다. 즉, 다른 컴포넌트에 이른바 '최대 공통 가용성(greatest common availability)' 요구사항을 적용하지 않습니다.

마이크로서비스가 애플리케이션 설계에 제공하는 세분성(granularity)을 통합에도 적용하여 비슷한 이점을 누릴 수 있습니다. 이것이 애자일 통합의 기본 아이디어입니다. 즉, ESB를 상호 종속성이 없는 세분화된 분산형 통합 컴포넌트로 나누며, 개별 애플리케이션 팀에서 이 컴포넌트를 소유하고 직접 관리합니다.

마이크로서비스에 관한 모든 것을 자세히 알고 싶다면 “마이크로서비스: 종합 가이드”, "SOA 및 마이크로서비스: 차이점", 그리고 Dan Bettinger 씨의  “마이크로서비스란?” 비디오를 참조하세요.