전통적 시나리오에서 서비스 소비자에게서 요청받은 로드 밸런서 라우팅 테이블 항목에는 서비스를 호스팅하는 한 개 이상의 서버 목록이 있다. 로드 밸런서는 이 목록에서 서버 하나를 골라 요청을 전달한다.
이러한 기존 방식에서 서비스 인스턴스는 한 개 이상의 애플리케이션 서버에 배포되었다. 애플리케이션 서버의 수는 대개 고정적이었고(예를 들어 서비스를 호스팅하는 애플리케이션 서버의 수가 늘거나 줄지 않았음) 영속적이었다(즉, 애플리케이션을 실행 중인 서버가 고장 나면 사용하던 것과 동일한 IP 주소와 구성으로 복구된다). 고가용성을 위해 유휴 상태의 보조 로드 밸런서는 핑(ping) 신호를 보내 주 로드 밸런서가 살아 있는지 확인했다. 주 로드 밸런서가 살아 있지 않다면 보조 로드 밸런서는 활성화되고, 주 로드 밸런서의 IP를 이어받아 요청을 처리했다.
이러한 모델은 사방이 벽으로 둘러싸인 회사 데이터 센터 안에서 실행되는 애플리케이션과 고정적인 서버에서 실행되는 비교적 적은 수의 서비스에서 잘 동작하지만 클라우드 기반의 마이크로서비스 애플리케이션에서는 잘 동작하지 않는다. 그 이유는 다음과 같다.
• 고가용성 로드 밸런서를 만들 수 있더라도 전체 인프라스트럭처에서 보면 단일 장애 지점(single point of failure)이다: 로드 밸런서가 다운되면 이것에 의존하는 모든 애플리케이션도 다운된다. 로드 밸런서를 고가용성 있게 만들더라도 애플리케이션 인프라스트럭처 안에서는 중앙 집중식 관문이 될 가능성이 높다.
• 서비스를 하나의 로드 밸런서 클러스터에 집중시키면 여러 서버에 부하를 분산하는 인프라스트럭처의 수평 확장 능력이 제한된다: 상용 로드 밸런서 다수는 이중화(redundancy) 모델과 라이선싱 비용이라는 두 가지 요소에 제약을 받는다.
대부분의 상용 로드 밸런서는 이중화를 위해 핫스왑(hot-swap)3 모델을 사용하므로 로드를 처리할 서버 하나만 동작하고, 보조 로드 밸런서는 주 로드 밸런서가 다운된 경우 페일오버(failover)만을 위해 존재한다. 본질적으로 하드웨어 제약을 받는다. 또한 상용 로드 밸런서는 좀 더 가변적인 모델이 아닌 고정된 용량에 맞추어져 제한적인 라이선싱 모델을 갖는다.