• 전통적인 로드 밸런서 대부분은 고정적으로 관리된다: 이 로드 밸런서들은 서비스를 신속히 등록하고 취소하도록 설계되지 않았고, 중앙 집중식 데이터베이스를 사용하여 경로 규칙을 저장한다. 대개 공급업체의 독점적인 API를 사용해야만 새로운 경로를 저장할 수 있다.
• 로드 밸런서가 프록시(proxy) 역할을 하므로 서비스 소비자 요청은 물리적 서비스에 매핑되어야 한다: 이 변환 계층은 수동으로 서비스 매핑 규칙을 정의하고 배포해야 하므로 서비스 인프라스트럭처의 복잡성을 가중시킨다. 또한 전통적 로드 밸런서 시나리오에서는 새로운 서비스 인스턴스가 시작할 때 로드 밸런서에 등록되지 않는다.
이러한 네 가지 이유로 로드 밸런서를 비난하는 것은 아니다. 로드 밸런서는 중앙 집중식 네트워크 인프라스트럭처로 처리할 수 있는 대부분의 애플리케이션 크기와 규모를 가진 기업 환경에서 잘 작동한다. 그리고 로드 밸런서는 SSL 종료(SSL termination)를 처리하고 서비스 포트 보안을 관리하는 데 여전히 중요한 역할을 한다. 로드 밸런서는 뒷단의 모든 서버에 대한 들어오고 나가는(ingress and egress) 포트의 접근을 제한할 수 있다. 이러한 ‘최소 네트워크 접근(least network access)’ 개념은 종종 PCI(Payment Card Industry) 규정 준수처럼 산업 표준 인증에 대한 요구 사항을 충족하려고 할 때 중요한 요소가 된다.
하지만 대규모 트랜잭션과 이중화를 처리해야 하는 클라우드에서는 중앙 집중식 네트워크 인프라스트럭처는 효율적으로 확장되지도 않고 비용 효율도 낮아서 제대로 작동하지 않는다. 이제 클라우드 기반 애플리케이션을 위해 견고한 서비스 디스커버리 메커니즘을 구현하는 방법을 살펴보자.