Perhaps the biggest impact on operations due to the abrupt migration of consumer and employee to digital experiences is availability. Certainly, a significant percentage of organizations struggled with remote access as workers moved from the office to the home.
Achieving high availability is not just a matter of inserting a load balancer into the data path. That’s part of the equation, but it’s just one of the steps needed to ensure an app or website stays available.
Therefore, according to F5 Networks, two not-so-simple questions must first be answered: How to distribute traffic between servers for high availability? And what level of health checking is required to properly validate a server’s availability.
How do you distribute traffic between servers for high availability?
If we want to make a traditional app (monolith, client-server, three-tier web) highly available, we must understand usage patterns from an entirely different perspective.
This is because one back-end “server” is responsible for executing all business logic. Trying to login? Ordering a product? Browsing the catalog? All the same “server.”
Since each business function has different compute, memory, network, and data requirements, each business function puts a different load on the “server.” A single “server” instance can quickly become overwhelmed simply by directing too many resource-heavy requests to it.
The best way to optimize distribution of requests to ensure availability for traditional apps is to use a least connections-based algorithm. This will keep load distributed across instances of “servers” based on the number of connections currently open.
For modern (microservices-based) apps, this question is more easily answered. That’s because a modern app is already decomposed into business functions that individually scale. It’s still a good idea to use a least connections-based algorithm because some requests for the same function may consume more resources than another, but traffic is naturally balanced in a modern app architecture so just about any algorithm will serve to keep all the “servers” available.
What level of health checking is required to properly validate a server’s availability?
According to F5, the following observation measures are required:
• Network connectivity.
• Transport capacity.
• HTTP platform.
• Application availability.
All four components of observability are important. If you lose network connectivity then the rest really doesn’t matter, after all. Therefore, you need to keep an eye on all four measures, which means checking them all.
It doesn’t matter what the app architecture is. All apps are dependent on the network, transport, and platform layers. Where the architecture makes a difference is at the app layer because the architecture may constrain the way in which you determine the app is working or not.
You should always ask for way to “health check” the app during development. The existence of a dedicated “health check” affords developers and ops an easy way to provide verification that the app is working correctly. This can include functionality that verifies connectivity to external resources like data or partner APIs.
Because failure of any of these components can cause the app to appear unavailable or unresponsive to the consumer, it’s important to verify availability of all required components.
High Availability is Harder than it Seems
Often, marketing literature would have you believe that high availability is as simple as cloning a server and shoving a load balancer in front of it. But the reality is that there are serious considerations, measurements, and preparation necessary to ensure that an app is highly available.
It’s not just a matter of making sure instances are available; it’s a matter of making sure all their dependent apps are available and distributing requests in a way that doesn’t overwhelm any given instance, notes F5.