Blue Stingray’s CEO, Brian Rehg, has been developing internet/cloud applications for more than two decades. This article details two applications that Brian developed during the ’90s while working in combination with the United States Air Force and the Department of Defense. While under the guidance of a four-star general, Brian developed several apps at the Air Mobility Headquarters located on Scott Air Force Base.
A few months ago, I was in a meeting at one of the larger startup tech hubs when I overheard someone say the most millennial sentence I’ve ever heard.
“If it wasn’t for Steve Jobs, we wouldn’t have the cloud.”
I almost dropped my complimentary latte. It had been a while since I’d heard something so inaccurate.
By “cloud,” they were likely referring to online backup. It’s true that Apple’s iCloud has brought the concept of cloud computing into the cultural consciousness, and with over 782 million users, it effectively rules the cloud storage market. It is, in technical terms, a beast.
However, it’s not the first product to leverage the power of the cloud—nor does Apple deserve sole credit for its innovative design.
Let’s back up (pun intended) to 1997, when the United States Air Force and the Department of Defense hired me to develop two cloud apps. Well, we didn’t call them “cloud apps” back then— we called them “internet applications” in the ’90s, then “web apps” in the early ’00s. It wasn’t until 2006 when the CEO of Google coined the term “cloud computing,” but I’m getting ahead of myself.
In 1997, I was hired by the Department of Defense and the United States Air Force to work on two projects. Both involved moving two existing clunky desktop systems into internet applications.
Tracking Military Planes Internet Application
The first project was to track all military and commercial aircraft for the DOD within a Netscape browser. If you remember Netscape, you know what kind of ancient technology we’re talking about here.
Bringing Stranded Military Planes Home Internet Application
The second project was to assist with the recovery of downed military planes that were stranded in remote areas. Prior to the development of the system, when a plane went down, an MRT (mobile recovery team) went to the site to assess the damages, rebuild the plane (if possible) and figure out how to get it to the nearest base. That meant physically traveling to the site, taking pictures, writing reports, then traveling to the nearest town with phone lines and mail service. There, the MRT would send the findings to headquarters before retiring to their hotel rooms to watch Seinfeld (hey, it was the ’90s).
At that point, they would wait for the appropriate military crew and equipment to arrive to complete their assignment. This process took weeks and cost taxpayers over $100,000 per day. Needless to say, there was room for improvement.
I was given a few months to create a better system—mostly on my own. To test my application with a satellite phone, I’d have to be escorted across the base by two MPs carrying M16s. That was quite tedious, and I’m fairly sure the MPs were annoyed at being assigned to nerd protection duty. They never spoke to me.
In any case, I had a pretty good idea of what I needed to do. My task was to create an internet application solution that included a CD tower farm (which held all of the schematics of military planes), an InmarSat briefcase telephone with a modem, a Libretto miniature laptop, and a digital camera.
Essentially, I was building a sort of proto-smartphone-tethering cloud app.
When planes went down in remote areas, the MRT teams could simply travel to the scene, access my application by firing up the InmarSat telephone, connect the Libretto to the InmarSat modem, and launch my app via the browser. At that point, they’d have access to all the plane spec sheets and wiring schematics. They could easily take pictures of the downed planes, share those images with the techs at headquarters, and communicate to determine their next steps.
The new system could get flights off of the ground in days, potentially saving millions of dollars per downed plane. It was an incredible system, but there was one problem: I hadn’t built it yet.
The first and most significant problem was getting the laptops to connect to the internet via the InmarSat setup. I had to trace every 0 and 1 that was traveling through the various pins of the cable that connected the laptop to the InmarSat phone. Once I found the pin that was causing the issue, I struggled for days trying to stop the garbage data it was sending back and forth. I finally took a pair of needle nose pliers and pulled out the offending pin, reconnected everything, and I was able to get the laptop online. The general had me pull the pin from hundreds of cables as they built and shipped the MRT recovery kits that I developed.
It certainly wasn’t the most glamorous gig, but I wish I’d known at the time that I was essentially developing the same type of cloud system that would power the world’s biggest companies in 2018. Essentially, this was cloud computing; multiple systems were working remotely to process and store information. Sure, we didn’t use that technology to store millions of pictures—that was a bit outside of our budget—but our “cloud” was certainly real.
So how did Jobs get the credit for a technology that was effectively in use for decades before Apple was involved with it? Probably the same way he got the credit for inventing the mobile phone and the tablet; he made the most popular version of the tech. He certainly deserves credit for that.
But really, while cloud computing now serves an essential function for just about every business in the world (including our own), it’s nothing new. Some might argue that “internet applications” and “web apps” aren’t the same as cloud computing. In a sense, they’re right; things change over time, and today’s systems are much more sophisticated than what we had in the ’90s. I still maintain that the early non-desktop developers were laying the groundwork for the so-called cloud revolution.