The Hierarchy of Application Needs

Most folks have heard or seen Maslow’s Hierarchy of Needs. If you aren’t familiar with the concept (or need a refresher), here’s the TL;DR – Maslow believed that people are motivated to achieve certain needs. He defined a five level hierarchy beginning with basic, survival-related needs like food, sleep, and security and moved upwards towards more personal, growth-related needs like self-actualization.

Suffice to say the hierarchy is often used as a model to describe a set of needs for a variety of concerns, including technology. Which is how we got here today.

There are a very specific set of needs applications have today that can be hierarchically arranged to mimic Maslow’s hierarchy. As with Maslow’s hierarchy, the lower level needs are the most critical to survival and success, while the higher order needs enable growth. Neat how that works, eh?

The reason this is important is that some of these needs can’t realistically – given today’s environment and user expectations and in some cases purely technical reasons – be met without app services. Those are things like load balancing, failover, web app security, SSO, acceleration and optimization, etc…

Sure, you could write an app that restarts itself in the event of a crash/failure, but you can’t address a network-level failure that causes an outage. Only an upstream (external) system like a load balancing or failover service can do that. Which means ultimately you can’t ensure reliability of the application unless you’re using an app service like load balancing. Similarly most applications can’t muck with the network stack that controls TCP behavior. But an upstream proxy (load balancing service) can, and it is there that many of the optimizations that make mobile apps usable are implemented. Without them, apps are slow and unresponsive and tend to be abandoned with higher rates than their optimized counterparts. That’s why performance is a mid-hierarchy need; because it’s important, but it’s not the most important need an application has. If it isn’t available, after all, no amount of optimization is going to help that.

So without further ado, let’s dive into the hierarchy of app needs, shall we?

1. Reliability

Reliability means users – corporate and consumer – can rely on the app being there. That means we need to make sure the app continues being available through periods of high demand (scalability), failure (failover), or disasters (disaster recovery). At its most basic it means load balancing and failover services, but also includes supporting app services like DNS that are responsible for redirecting users in the event of a disaster. It’s no surprise that availability has remained at the top of the “app services organizations would not deploy an application without” in our State of Application Delivery surveys. It’s not just a basic app survival need; today it’s a business survival need, too.

2. Security

Ah, security. Without it, apps are vulnerable to a wide variety of attacks, not all related to the quality of their code. Application security is a stack, comprising not just the app but its underlying platform as well. And reports continue to indicate that attackers are continuing to move up that stack, toward the application layer, for both exfiltration (to steal ur data) and exploitation (to stop ur business). That means a variety of security app services are needed to help the application stay available and healthy, like DDoS protection, web app security, fraud prevention, and encryption services. The increasing frequency with which organizations experience attacks and new vulnerabilities are reported continues to drive security needs as one of the core app services necessary to ensure the survival of apps and business today.

3. Performance

Performance. We all know how important that is, particularly for apps commonly used via mobile devices (over a mobile network). Performance app services are the level in the hierarchy that crosses from app services addressing basic needs to addressing growth. Performance-related concerns are really about both. If an app is too slow or unresponsive, it can negatively impact productivity of corporate users as well as reduce revenue from consumers. It doesn’t have the same impact on the business as the app being unavailable or experiencing a breech but it’s still important. That’s why we see so many organizations employing techniques like image optimization, compression, SSL offloading, and TCP multiplexing to improve the performance of applications. Because sometimes it isn’t about the code; it’s about addressing challenges in the network, on the user’s device, and with the protocols over which applications communicate.

4. Programmability

Apps are the business today, and they must be not only delivered fast but deployed fast as well. To grow and scale means the app services supporting the lower level needs (reliability, security, and performance) must be able to be deployed fast, too. That means programmability. It means APIs and templates, and being integrated and accessible to the other API economy driving the CI/CD pipeline out of dev, into ops, and across the broader IT spectrum. Programmability enables app services to participate in the DevOps ecosystem whether it’s focused on the network (SDN) or cloud (OpenStack) or the entire data center (SDDC). Templates provide standardization (consistency) and the repeatability necessary to improving the processes that drive deployments in modern data centers. APIs ensure flexibility and support for the growing number of frameworks and toolsets used to automate configuration and management, and ensure that no app is left behind because the network was in the way.

5. Architectural Agility

Finally, to support app (and thus business) growth today, applications need architectural agility. That means the app services that support and enable and protect them must be compatible with the architectures the apps are using (like microservices, containers, virtualization, and cloud). The app services supportive of the lower level needs of the hierarchy must be available for deployment along with the application wherever it might be going. That means support for virtual, physical, and cloud-based app services.