2012 Prediction: Reflex Systems

Aaron Bawcom (Profile)
Thursday, December 8th 2011

The Application Friendly Cloud – Getting from First Date to Long-Term Bliss

Relationships usually start pretty well. In the beginning, everyone is on their best behavior and will go out of their way to make things easy for one another. Then, around the third date, you find out about that particular medical condition or what colors will be used in the wedding. Just like people, the courtship between our beloved applications and "The Cloud" has started off showing great promise. The cost of running our applications has decreased, our applications are magically up to date whenever we use them. And if that server hardware dies you are not getting calls at 3AM to deal with it.

But now that applications and the Cloud have been going steady for a bit, we are starting to discover where there is room for improvement in the relationship. First, applications love API's. SDK's, SOAP, REST, code libraries, messages, etc. are how applications interface with the environments they run in. So the hip applications for the Cloud take advantage of the API's that are offered by Cloud vendors. The problem with this approach is that adding a specific Cloud vendor's API to your app is like writing a web application that only works with one web browser. Yes different Cloud vendors have similarities but the application bears the burden of supporting each Cloud vendor.

In addition to using Cloud API's, modern applications need deep granularity, visibility and control of the environments they run in. Applications thrive on simple, well-defined, programmatic access to the services they consume. Applications also use low-level resources such as memory, processing, and disks or higher level services such as databases, component software, networking, load balancing, disaster recovery, high availability, application performance data, or security. Each type of service can be offered in 20 different flavors by 20 different vendors, and to further complicate things, each one of these combinations may be delivered by each Cloud vendor in a different delivery model (think SOAP, REST, XML, Json, etc.)

One answer for these problems is the concept of a Cloud broker or proxy. This "middleman" approach does offer some advantages but it is another moving part between the application and the actual Cloud which must be maintained and diagnosed if something goes wrong. These types of services will continue to grow, but there may be other approaches that gain more steam.

So if we do a relationship check, applications want more services that are easier to consume in standard ways and Clouds want to provide more services that make it simpler for applications to run on them.

One of the best ways to forecast the future is to look at the past. The good news is that these types of relationship problems have happened before and some great solutions emerged to solve them. In the 1970's, the industry struggled with the challenge of storing and retrieving data. Vendors had specific API's for their products that provided generally the same capabilities but each vendor offered different features and the delivery of those features via input/output were different as well. What emerged as a solution was a domain specific language for queuing and modifying data called SQL. Using a language to describe the storage and querying of data made it possible for databases to offer a simple well defined interface to applications. Each vendor backed the language with their own special sauce and the end result was that applications could use a single centralized language which made it easier to switch from one database to another.