To fully embrace AlwaysOn with its ideal utilization of secondary servers, developers must modify applications
support the read-intent string as part of the SQL connection parameters for that traffic to connect to a secondary.
let your application know which queries can be sent to a secondary server,
Does not support true load balancing within AlwaysOn
Redirects a read-intent connection to a random secondary server in the availability group.
the database doesn’t know which server is the least loaded or closest to the application asking to make the connection, which really matters when the secondary servers are located across separate networks for disaster recovery (DR) or high availability (HA).
All this intelligence is very hard to code into the application and requires considerable maintenance whenever you add or remove servers to the availability group.
Because these application modifications represent fundamental architectural changes, they can take hundreds of hours of application developer time to complete. They also require extensive testing to validate how the code works in the complicated AlwaysOn environment. Unfortunately, proprietary off-the-shelf applications can’t be optimized at all in this way, since you typically don’t get source code access to those applications.
Enter database load balancing software. It works at the SQL networking layer and offers simple ways to take advantage of AlwaysOn without the hassles that usually come with it.
How to hit the happy medium:
Don't allow your secondary servers to play second fiddle. They should be processing read traffic -- and without modifying apps first. Load balancing sw sits between apps and the db and requires no mods to apps.
It knows the difference between read and write queries and shares the load between servers making traffic fast and efficient.
Replication lag is an unavoidable fact that creates data inconsistencies and applications don't make it easy to fix. Primary and secondary servers are never exactly in sync. But db load balancing sw monitors replication and load balancing and even notifies admins of the cause.
Core-based licensing makes modern SQL expensive. But load balancing sw means companies need fewer cores. Secondary servers are made to work harder and repetitive queries are cached so db servers process fewer of them.
Modern SQL's multi-server environment makes visibility even more challenging. Want a comprehensive picture of what's happening across a system? Good luck. But db load balancing sw offers real-time views into queries and analytics allowing ops teams to react accordingly in real time.
If your 'failover architecture' is failing you because it doesn't go beyond one data center, migrate load from one center to another with seamless db load bearing sw. Get true and fast read/write split that's easier and more effective.
--