Software ate the world. Then SaaS started eating software. Then, cloud started enveloping SaaS.
Now, even one flavor of cloud is no longer good enough for most highly distributed software applications. To be agile and responsive, you must orchestrate the delivery of applications across some kind of hybrid public or private cloud, which could be provisioned from service providers, called via APIs from a marketplace, or deployed into ephemeral cloud-native microservices.
The push for off-premises migration of software has never been stronger — by some architectural estimations, it’s taken for granted that most applications should move to the cloud in the next couple of years if they are not there already.
But wait, why are some companies hitting that big red disconnect button today, and doing on-prem air gap software installs?
If you are new to the concept of air gapping, that’s OK. Old hacks like myself with some history of supplying software for banks and government agencies have encountered the need for air gapping — basically, installing onto a system that is not connected to the Internet at all — nor any network that could offer any port for security breaches to occur.
Basically, air gapping is the purest form of on-premises software delivery, in that absolutely everything needed for that software to run must be packaged for local installation and ready to run disconnected from any network.
No calls out to external authentication providers. No remote license keys. No checking for version updates and patches. Sneakernet installation, we called it, meaning someone would need to walk in with a disk or drive and manually execute the install onto the target air gapped system.
Once on-site, ideally, this would have been a double-click, plug-and-play event — but often, the configuration, install, and patching process for one of these systems was a Sisyphean effort.
Vendor product experts and customer sysadmins would work together to run batch scripts, tweak manifest settings and validate the system, sometimes through terminal consoles, once it went live. Mess one step up, or realize the need for a later product update, and both sides would be looking at another extended and costly consulting visit.
It’s not hard to tell why air gapping was reserved for only the most mission-critically remote use cases. Many software vendors simply chose to opt out of this side of the market, waiving their right to work in such secure demesnes in favor of less troublesome Internet-friendly SaaS business models.
If you were to believe pundits who made SaaS and cloud computing predictions ten years ago, we’d be operating everything-as-a-service by now. But for many kinds of secure work, SaaS isn’t a viable option, and even connections to external services and APIs are undesirable.
I was stunned to find out from a 2021 study on The State of On-Prem that customer demand for on-premises software is almost equally as high as for public and private cloud options — and that more than one-third of customers surveyed wanted to procure air gap software.
This flies in the face of expectations of the modern cloud-driven software market. Still, it hits home when you scratch the surface of providers that deliver effective enterprise solutions to regulated or sensitive IP scenarios.
Serious enterprise vendors will still have services teams or certified partners performing on-prem air gap delivery, as well as a support team that provides packaged installs and documentation for just such scenarios.
If air gapping offers so much potential hassle, why would the practice become popular again lately?
There are several good reasons why companies are reconsidering air gap installation.
If the company still has the inertia of systems that shouldn’t be moved or tampered with in its data center, why not install new modules and software as close as possible to these critical systems? Better responsiveness is a welcome by-product of co-location, especially on the mainframe.
Government regulations and industry policies for retaining sovereignty and local control over sensitive data continue to evolve, and with it, so do the penalties for non-compliance and SLA failures. Certifying an air gap installation is a great way to pass even the most demanding audit.
Millions of automated exploits and attacks are seeking out threat vectors for sabotage, theft, and data exfiltration at any given time. Ransomware is perhaps the worst of it, as the target of the attack is your data itself. Air gapping by nature offers almost zero threat surface (other than perhaps an inside threat) and is also perfect for disaster recovery scenarios.
The widespread adoption of containers to replace VMs — and Kubernetes (or K8s) as a common reference architecture for orchestrating their deployment — isn’t just the factory enabling ephemeral workload cloud-based applications. K8s also offers on-prem installs and updates a far more stable and repeatable complete environment definition. This is huge, so expect us to write more on this thread later.
Modern architectures with better modularization and portability, and new multi-prem installation solutions such as Replicated, bring down the TCO of rolling out and maintaining air gap software installations.
Given the well-known failures of many previous modernization efforts to maintain application and data integrity in the wild over the years, I wouldn’t blame a company with critical software for staying the course with yesterday’s on-prem install processes.
Still — this ain’t your grandma’s on-prem software anymore. We are now seeing evidence that air gapping is not just a matter of isolating data and controlling software to meet regulatory requirements.
Air gapping is a unique form of on-prem software that can be pretty advantageous in real-world business scenarios, as we’ll cover in our next installment.