We may not be aware of it, but as developers, we create applications that introduce risk into the lives of others.
That may sound harsh, but it is true. Worse than introducing risk, we force others to shoulder the impacts of the risk. We do it because our work is evaluated on a well-defined list of measures. Rarely do we implement user story that says something similar to ‘As a user, I want the application to work during hardware failure so that I can do my job’.
Nor do we see user stories around attacks from malicious actors. Instead, we implement features that are meaningful when the application and infrastructure are working correctly. Production experience tells us that life happens to our infrastructure, our technology stack, our environment, and our apps. We can no longer ignore the realities happening around us. We can do better. As developers, we need to mitigate the risks we impose upon others.
All apps introduce risk
All valuable apps introduce risk. You might be thinking why that is. Risk from apps can take many forms, but the most basic risk is that of dependency. If the app is valuable, then people depend on it. If people depend on it, then problems arise when the app is unavailable. All the app has to do is be valuable and unavailable for it to create problems.
If the app is capable of creating problems, then the app introduces risk. Even if the app introduces no other risks, it can create this dependency risk. What about apps used not by people but used by other apps instead (i.e. services)? Since no person depends on them, do services introduce risk? Yes, and even more so. A service has a dependency risk not by people, but by other apps. Each of those other apps can impact people.
Because of cascading dependencies, a service can introduce even more risk than an app. Of course, other risks are possible. The app could introduce data exfiltration risk. A poor security posture could invite attacks and perhaps a breach. Weak performance design might risk degrading the user experience. Suboptimal TLS architecture might increase the risk of private key exposure, in turn introducing more risk. The list goes on and on. Any app that people use, even indirectly, introduces risk.
The risk introduced often manifests as impacts to other groups. Developers may create an app, and operations may deploy it, but realized risks fall on the shoulders of other groups. When an app becomes unavailable, the end-users cannot do their jobs, the helpdesk receives complaints, incident managers engage analysts to find the failed component - only then has the organization identified the app team that can recover from the failure.
Imagine the widespread impact of an intermittent brownout or other performance problems. Even worse, consider the number of groups disrupted by a breach. Individuals and groups outside of the development and operations team bear the brunt of impact. Wise development and operations teams understand that their app imposes risks onto others.
Mitigating Application Risk
There are steps we can take to categorize and mitigate risks by understanding how apps are structured and inter-dependent.
Availability Loss - The most basic form of application risk is availability. An application could become unavailable for any number of reasons. Should an instance fail, load balancing can ensure availability through the remaining instances. Should an entire data center fail, global server load balancing (GSLB) will direct traffic to the surviving data centers. Should standard DNS servers become compromised or attacked, hardened DNS servers can continue to resolve host names.
Performance Loss - Similarly, performance could suffer due to several causes. Traffic steering can direct traffic such as static content to specialized nodes. Caching reduces the load on the server pool, as does SSL proxy. TCP optimization compresses the content and provides optimal packaging of the payload for the client.
Malicious Attacks - Finally, the application could become an attack surface area for malicious users. A Web Application Firewall (WAF) can minimize attacks such as SQL injection and cross site scripting. An advanced SSL proxy can decrypt traffic for analysis by security devices, including sandbox devices and intrusion prevention systems.
All important applications introduce risk. If nothing else, valuable applications introduce availability risk while others shoulder the risk impact. As a result, developers can unintentionally expose other groups to risk.
Development and operations teams can use advanced application delivery services to mitigate risk and reduce impact and organizations can offset loss of availability through several means, such as DNS, load balancing, or DDoS protection. Traffic steering, caching, and TCP optimization can reduce risks of performance loss. SSL proxy, WAF, and anti-malware can reduce risks from attack.
These and other advanced application delivery services help ensure that your application does not expose users and others to unnecessary risk.