We've come to expect Internet connectivity to be available because the provision of it has become so cheap. And that expectation has led us to become reliant on it. When the Internet is down for us, many of the things we do become unavailable. This reliance on the Internet has made planning for the lack of it complicated. Many organizations are, in effect, crossing their fingers rather than planning in earnest.
Often when it is unavailable, the solution is more or different Internet connectivity and other redundancy: If your servers or data center go offline your company and your customers may be out of luck. If you have a real cloud architecture with redundant Internet connections, even redundant data centers with replication of software and data, you can stay in business.
I spoke with Adrian Sanabria, Senior Analyst, Information Security at 451 Research. He asks "[i]f the primary goal is to keep your applications up and running and your data accessible, does it make sense to even have an offline model? Especially when a connection to the Internet is so easy to come by?" And he's right. From the point of view of keeping your server-based applications accessible, the cloud is the best answer. I would add that, by the same logic, large public clouds, like Amazon Web Services and Microsoft Azure are similarly natural because they give you massive redundancy and worldwide reach without having to build your own data center.
But what about client-side outages? It used to be the case that you could generally expect your applications to work even when the network was down. This may or may not be true anymore. An offline model for web-based applications is possible and standards, such as Service Workers and IndexedDB, are emerging for them. Still, it's bad to be disconnected to everyone else and some applications can't reasonably be expected to work with inconsistent access.
Big companies with the budget for it have backup. As Sanabria puts it, "[m]ost larger enterprises already have a few fallbacks if one Internet connection goes out -- at least two providers, with different paths into the building, some using 4G as a third fallback."
There are two problems with this: One, as Sanabria points out, is that if you don't actually test your failover backup service from time to time, you shouldn't be relying on it. The other is that often separate Internet sources will share some vulnerable infrastructure, such as wires on the same utility poles.
And parenthetically, if you're not spending a fortune running your own data centers you can justify more budget for Internet access contingencies. But Sanabria thinks it's increasingly not worth it. Just give your employees 4G-enabled laptops or phones that can be hotspots. It's true that businesses are increasingly allowing for remote work and disaster planning is a good argument for it.
It may even be worthwhile as an exercise. Require employees to have a plan for working offsite and schedule a day for everyone, or perhaps one department at a time, to do so. You might learn something about productivity while you're at it. 9/11 proved that it's possible your offices may be out of commission for a while. Do you really want to have to make up your plans on the spot when that happens?
I'm not as confident as Sanabria about enterprise readiness for Internet outages. I've always been skeptical of 4G as a backup for an organization. If the Internet is out for a large area then everyone will be hitting on the 4G networks, and I suspect they would become much less reliable. But clearly the world is moving in the direction of what he describes and the bandwidth and reliability of those networks is increasing.
And if you're not that big an organization? If you have just one main office building you have to consider the possibility that it will be out of commission and/or that your Internet access will be gone. First, the cloud is definitely your friend. You can't afford for some key SQL Server at your office to be inaccessible.
How seriously does your organization plan for outages? Please tell us about it in the comments.