The Cloud Falls Short
The cloud provides tremendous leverage for individuals and companies that don't have a lot of extremely sensitive data or laws around their data handling. But for a growing number of businesses in fields like health, defense, or financial services, the cloud simply isn't an option, due to strict regulation on data storage and handling. For example, any company that engages in financial trading is required to preserve much of the information generated daily -- like emails and trading records -- for anywhere from a year to indefinitely. Without the ability to monitor and house this information on company-owned servers, businesses in these fields do not have the option of using managed services that live on faraway computers.
Yet clearly, these are some of the businesses most in need of disruption. I recently sat on an airplane next to a COBOL programmer that worked for a large insurance company. COBOL -- a programming language first devised in 1959! However, guys like this are still around to manage the legacy systems, likely more than 20 years old, owned by this insurance company. Instead of focusing on innovation and operational optimization, companies with huge legacy systems are instead simply trying to stay afloat on entrenched systems. Sounds ripe for disruption! But without the ability to gain the leverage possibly by managing large numbers of users centrally, startups simply won't be attracted to the problem or the industry.
The solution is what I'll call Environment as a Service (EaaS). The idea is relatively simple -- providers produce software that they then package in a turnkey software environment image. The images can then be dropped into any computer with some minimum specifications -- either a physical box or [more likely] a virtual machine set up with the required resources. The client companies would own the physical computers, and would be responsible for low-level functionality like hardware and connectivity. The providers, on the other hand, would be responsible for everything else -- ensuring software functionality, security, and updates. Services could be knit together through well-understood interfaces to ensure easy swappability -- imagine an internal microblogging EaaS that wrote out all storage needs to a Dropbox EaaS. To swap out one microblogging EaaS for another (eg, the Twitter EaaS for the Yammer EaaS), you'd simply have to ensure they could understand each other's data, and point them to the proper storage EaaS.
The beauty here is that the clients now own (as in, physically hold) their own content. If they want to erase it, they can do so simply by reformatting their own box and destroying their own backups (or destroying their Backup EaaS box) -- they don't need to worry about the compliance policies of a third party cloud vendor. They can control their own security -- choosing arbitrary firewalling or access procedures -- without worrying about a startup that might not have the same security priorities. Finally, and most importantly, they can reap the benefits of off-the-shelf software solutions without installing applications (just images), worrying about operating system compatibility, or troubleshooting security patches.
The benefits of this arrangement to the client are clear -- the advantages of the cloud with the peace of mind and regulatory compatibility of "on site" data and computing. For the providers, creating a plug-and-play, turnkey solution that would allow their app to easily function offsite would open up new revenue lines in industries that were previously untouchable. The intermediate solutions today, such as the Google Search Appliance, are a step in the right direction, but fall short on a number of goals, such as open APIs and ease of deployment. The emergence of a well-documented, industry standard EaaS system would mean thousands of new, deep-pocketed customers for the providers, a rush of development and cutting-edge innovation for the clients, and better systems and products for the people that depend on these services.
