Damals in den jungen Tagen des kommerziellen Internets entdeckten viele Möchtegern-Dot-com-Millionäre ein ernsthaftes Problem in ihren Businessplänen. Mainframes besaßen noch nicht eine entsprechende Web-Server-Software (bis zum AS/400e, sowieso nicht) und selbst falls doch, war sie nicht mit ihren Startup-Budgets finanzierbar. Was sie sich leisten konnten war Server-Hardware aus dem Standardregal der allgegenwärtigen PC-Hersteller. Das Problem dabei? Es gab keinerlei Möglichkeit, dass ein einzelner, PC-basierter Server jemals in der Lage gewesen wäre, die Menge an Traffic zu verarbeiten. Im Fall eines Serverabsturzes auf Grund dieser Problematik, würde das einen erheblichen geschäftlichen Verlust bedeuten. Glücklicherweise hatten manche dieser Leute tatsächlich weitergehende Pläne, indem sie dieses bestimmte Problem lösen wollten. Dies war die Geburtsstunde der Loadbalancer.
Software mit integriertem Loadbalancing
Eine der ersten, speziell angefertigten Lösungen für das Loadbalancing-Problem war die Entwicklung von direkt in der Anwendung oder dem Betriebssystem des Servers integrierten Loadbalancing-Ressourcen. Solange es so viele Firmen wie verschiedene Anwendungen gab, waren die meisten Lösungen Augenwischerei. Zum Beispiel machte eine Lösung alle Server eines Clusters, zusätzlich zu ihrer eigenen physischen IP-Adresse, über eine Cluster-IP aufrufbar.
Die zweite Welle spezieller Loadbalancing-Lösungen brachte Netzwerk basierte Anwendungen hervor. Diese Geräte sind die wahren Gründerväter der heutigen Application-Delivery-Controller. Da diese Geräte anwendungsneutral sind und sich außerhalb des Anwendungsservers befinden, können sie Loadbalancing erreichen, indem sie viel überschaubarere Netzwerktechniken nutzen. Im Wesentlichen wird eine virtuelle Serveradresse an die Außenwelt gesendet, die bei Bedarf eine Verbindungsanfrage an den geeignetsten Server über bi-direktionale Network-Address-Translation (NAT) weiterleitet.