I really enjoyed Jeff Atwood’s recent blog on Scaling Up vs Scaling Out, which includes a fairly detailed comparison of the costs associated with each approach to scalability. I enjoyed it because not only did it take into consideration the cost of hardware, but also remembered to include the cost of software licensing. And of course there’s the fact that Jeff’s site is focused on development and coding, and this discussion  broadened the discussion into the realm of application networking – a demesne with which I am of course particularly fond.

Now the problem is – and you knew there had to be one, this is me after all – that the discussion is primarily about scalability. Scalability is good, of course, but it’s not the whole story. The discussion stemmed from an inability of a real server to meet capacity which resulted in the dread d-word: downtime.

Scalability is of course a Very Good Thing. There’s no disputing the fact that it’s absolutely critical to ensure that applications scale – one way or another. But simply ensuring scalability should not be confused with providing reliability because even a scalable application can end up “unavailable” despite having access to vast amounts of resources.

WHAT AVAILABILITY REALLY MEANS

The other half of the reliability equation is availability. At first glance it may appear that scalability automatically ensures availability, but that’s simply not true. There are several reasons why these two are not synonyms and should not be treated as interchangeable. First, in a business  environment availability is not just accessibility – which is ensured through scalability -  but timely accessibility. An application that does not  meet its agreed upon service level agreements is not considered available. Abandonment rates increase dramatically as performance degrades and productivity plummets when applications are slow to respond.

Second, availability can be affected by other mitigating factors such as security. The recent (and ongoing) attacks on U.S. government websites, for example, are primarily denial of service attacks. Such attacks are focused on consumption of resources, and not just server resources but network resources as well. After all, it doesn’t matter how fast an application responds to a request if the response is going to be “stuck in traffic” as it were. A successful attack on the application targeting some known vulnerability, too, can result in the dread d-word by causing crashes or otherwise corrupting the application’s ability to service requests.

Thirdly, availability can be affected by applications that perform correctly at nominal load levels but which become unstable at high load levels. The simplest of examples of such a situation involves database connectivity. At high load levels it is often the case that an application server’s connection pool is simply not robust enough to keep up with demand. No amount of scaling up will solve this problem, because it isn’t a hardware resource issue, it’s a software resource issue that isn’t even under the control of the developers because the connectivity is provided by a third-party – the web or application server vendor. While the application server may be responding even under heavy lead, an application without data is really quite useless and, like failure to meet service level agreements, by business standards it is considered unavailable.

ACHIEVING RELIABILITY

In order to reach reliability nirvana, i.e. five 9s with consistent adherence to service level agreements, you cannot rely on scalability alone. It just doesn’t address all the factors that are necessary to ensure the availability required for a reliable application or site. You need to address three potential points of failure in the application architecture to avoid potential downtime:

1. Performance
   Adherence to service level agreements are, admittedly, a pain in the proverbial rear-end because it seems like so many factors are often out of the control of the developer because they are. And yet developers are the ones often blamed for poor application performance. The application infrastructure needs to provide tools and mechanisms that can counter the natural tendency of application performance to degrade as capacity increases.
2. Security
   Security needs must be addressed and not just the typical application vulnerabilities. Security needs to be aware of the potential for resource consuming attacks for which the purpose is to take a site or application “offline” as opposed to exploitation for other purposes. The security architecture must address both network and application security as a means to prevent an application from becoming unavailable.
3. Functional correctness
   Applications must respond – and respond as expected – under myriad levels of load. In order to ensure this is true the application must be monitored in such a way as to report not just network or transport layer failures, but application response errors. This requires intelligent monitoring – the ability to not only check connectivity, but validate content for correctness.

None of these can really be addressed by the application itself, because the measurements and monitoring required must occur outside the application. That means some other solution must be responsible for providing availability of applications.

The best solution is a unified application delivery solution, because it brings together – as the term implies – the disparate external functions necessary to availability assurance in a single solution. Application and network security, bandwidth management, acceleration and optimization are all a part of application delivery platforms, and it is that platform that will provide the best chance for realizing true reliability of applications and web sites through the assurance of availability. A solution such as a unified application delivery platform is external to the application and, if you’re scaling out, you’ll need its core functionality of a load balancer anyway. This means it can monitor for functional correctness, provide network and application security, and offers a variety of acceleration and optimization features that can manage performance needs.

Related blogs & articles:

• Government Web sites attacked; N. Korea suspected
• Scaling Up vs. Scaling Out: Hidden Costs
• Layer 4 vs Layer 7 DoS Attack
• To Boldly Go Where No Production Application Has Gone Before
• Green IT: Reduce, Reuse, Recycle
• Cloud Computing: Vertical Scalability is Still Your Problem

Read the original blog entry...