I recently read an article exploring the idea that new tablet devices, including the iPad, will create a greater demand for SaaS and cloud storage.  This is an interesting perspective to me because I don’t think we’re too far away from the day when “iPod as a service” becomes a reality and there is no more need for DRM.  Paying $9.99 a month for listening to any song ACROSS any compatible device you have, and having the option not to “own” any of the albums or songs sounds good to me.  Rhapsody has an early model in place already that does this to an extent (it supports a few devices, but not ANY device). With the continued development of “As A Service” business models and frameworks I can’t think of a reason why iTunes or a future “Google Tunes” cannot do it tomorrow

What used to be called Storage Area Networks a decade ago and was intended to make enterprise storage more robust and accessible is now commoditized and called the Storage Cloud. Computation is also becoming an accessible commodity with the Elastic Compute Cloud. Access to applications and storage is now more consumer friendly and unlimited. If you think about it we’re in a sense going back to the Mainframe days. Only now you can access a “mainframe” with theoretically unlimited computing and storage power, for personal use, through your phone, sitting on a train and not just for dedicated scientific or business applications. Everything is becoming more seamless and transparent. For once we needn’t worry about operating environments, compatibility, or file formats. We can now focus less on the Information Technology and more on the Information.

The defining characteristic behind the adoption of any pervasive computing enabler (SaaS being the front runner right now) has been the degree of mobility of the associated commercially available User Agent (iPad, iPhone, HP Slate, Android devices like ICD Gemini etc). While it can be argued that these devices are still in their infancy, if Moore’s law is anything to go by, we’ll see significant improvements in associated enabling technologies, specifically connectivity and bandwidth, as these devices gain market share. As the enablers do more the devices themselves need to do less without overall loss of functionality. In other words pretty soon you will find fully functional clients getting smaller and thinner simply because the technology has matured to the degree that storage and computation is not a constraint anymore. Just so long as you are connected to a pipe that’s fast enough to shuttle data back and forth without latency (IEEE 802.16 anyone?).

Taking the idea of smaller sizes and integrated capabilities a bit further I can’t help but imagine what new possibilities nano-scale technologies and quantum computing will offer in the near future. For those more inclined towards theoretical computing foundations there seems a greater push to look beyond the traditional Church-Turing conjecture that all computing technology based on registers and pointers is arguably inspired by. What seemed like sci-fi fantasy 20 years ago is in our pockets today. Mark Weiser’s Smart Device is now a reality, the internet of things is probably not too far away. By all indications could “Hyper-computation” be doable in 20 years or less? Regardless with the advent of full virtualization, on demand licensing and increased bandwidth we’re in for some good times ahead!

I’m sure several things come quickly to mind when someone mentions cloud computing or cloud applications. As Mark noted in his post about different emerging cloud services there are several layers of complexity that might flavor an application built on or with cloud services. I’m going to specifically talk about building applications that consume or consist of cloud services, Software as a Service ( SaaS ). These can be services you build yourself or they can be 3rd party services. At any rate your end goal would be to have an application that can be delivered to your users, built upon cloud services and my goal is to describe the different layers of how you can build that application based on my experience of designing/building cloud based applications.

I tend to think of the cloud just as I would a traditional computing solution with a few caveats: cloud computing should be highly scalable, on demand and more cost-effective than something I could get at my local web hosting company. At least in theory. In five years time, what we think of  as cloud computing will probably be the “traditional” computing solution,  indeed you will notice that the layers I’ll describe already follow how web applications are generally built today. The reality of the situation means that while cloud computing solutions offer more for less, the trade off is that no one service can be 100% trusted, no one network can always be relied upon, and therefore fault tolerance must be built into the system.

So let’s break down the anatomy of a typical web based cloud application. Generally speaking applications fall into 3 layers, 1) Persistence Layer, 2) Processing Layer and 3) Presentation Layer. These layers can consist of several different services, from several different cloud computing vendors or api’s. You should feel free to have all of these layers talk to each other as well.

So, for the Persistence Layer you might write to a EC2 hosted MySQL database for app specific data, while also relying on the the Persistent capabilities of Facebook, Twitter, or even Google to store user specific data. When I think of the the Persistence Layer I think of only reading and writing data to disk. There should be no (or as little as possible) logic associated with this layer because any logic you write will tend to be platform specific making it more difficult to port in the future event you have to switch providers. In most cloud computing solutions this layer is the layer that implements Eventual Consistency. Interactions with this layer should be quick and to the point. You write, you read. Period. It doesn’t happen often, but if you were to move your persistence layer from one vendor to another, it should be a simple as transferring files.

The Processing layer ( just like a traditional application ) is the layer that interacts with both the Presentation and Persistence layers. This could be a layer you write in  your favorite server scripting language. It could be a proxy layer that you write that takes input from your application and then routes data to other third party services, with some of it  going/coming from Amazon SimpleDB, some of it going to a legacy database from with your network, and perhaps it ferries analytical information to Google Analytics or Omniture. The point is that, the processing layer can be used for any type of processing that your application needs.  But keep this in mind, in my experience the more you proxy to third party services, the less code you’ll have to write and maintain. Or to look at this from the other side if you’re using a third party API and your application doesn’t need to augment the data before sending it over there should be no reason to build a processing layer. Mashups can be thought of a cloud application without the Processing Layer. Can your Presentation Layer talk directly to Omniture or Amazon S3? Absolutely, as long as you don’t have application logic that needs to run before you read or commit.

The Presentation Layer is where everything gets tied together. Above all it needs to always be responsive. I’d go so far as to say that it’s development specific limitations should drive all other development, when possible. I realize that might be a bit controversial, but remember in most use cases, the Presentation layer is running on a user’s machine, which can be thought of just another machine in the cloud. The user is allowing us to run the application on his/her processor for free with the implicit expectation that the application will give something back. The very least we can do as developers is to make sure the user knows what is going on. The need to pull data from multiple locations and present in a data rich interfaces is what makes technologies like Adobe Flex and Microsoft Silverlight so appealing to developers.

So, as a quick summary about what to think about when building cloud based applications. Build the Presentation and the Persistence Layers first and only add the Processing Layer as needed. Never trust any one server or any one network. Practice failure to help build Fault Tolerance. And last but not least, the most important fault tolerance you can build is on the Presentation Layer.

In posts to follow I’ll take a deeper look at each of these layers, various options for these layers and talk about some the lessons learned and best practices for building applications upon cloud services.

Part I:  A Little Background

Saas – Software as a Service
Paas – Platform as a Service
Iaas – Infrastructure as a Service

If you are already familiar with these three acronyms, skip to Part II…

Software as a Service is the most common form of interaction with the cloud.  As previously mentioned, Salesforce.com, a pioneer in this category, has an API that enables you to write programs that extend the features of its service.  In other words, you could write a program that automatically pulls your account leads from Salesforce.com, scans the status of each account and conducts a relevant news search (using other APIs) for idle accounts.  Reports can be generated based on the aggregated data.  The news search service API could be google,  reuters, blogs, rss feeds etc… This type of API-enabled service is widely available across many websites.

Once you have a program that accesses services using an API, then you may have a problem because you want the program to run all of the time.  You can’t run it on your machine, because you don’t want your machine to be running the program all day.  You can’t run it on a web server because it will impact the performance of your website (same with the app server etc…).  You could however write the program and run it in the cloud on a virtualized platform.  This type of the cloud is known as Platform as a Service.  You have essentially chosen a provider that runs the platform you develop on and are comfortable with.  You therefore lease some computing space to execute your program.

Now that you have a report being generated by a program being run in the cloud, what about the distribution of that report?  If you want to make the report available to the very edge of the network across the world as quickly as technically possible, then you could leverage a provider that distributes and caches the report file on servers throughout the world.  This is an example of leveraging Infrastructure as a Service.  Services like Amazon Cloud Front maintain distributed servers for just that purpose.

Part II:  Opportunity

Another way to view the different cloud concepts is to recognize that they are mainly about how systems interact with other systems.  Why is this important to me?

Opportunity

• You should know your options
• Demand for real-time data is growing
• Tech-savvy departments can have more freedom to roam in the cloud, without IT constraints
• Diversification- resell your own data processing services in the cloud.
• Make your services more widely available
• Integration- once an ecosystem of services exists, complete with service adapters between standardized formats, integration efforts can be reduced.

Potential Cost Savings

• Pro-rated licensing charges on a per use basis
• Scale on demand- provision new servers as needed
• Consolidation of resources to manage
• Start-ups may use the cloud to keep costs down and to focus on core competencies, rather than buying equipment upfront
• Larger IT departments with a data center can get more breadth of range using the cloud without hiring a system admin for a new/different platform

Source: Gary Larson’s The Far Side

There are many factors to consider when looking at the cloud.  Greg Shipley, CTO of Neohapsis, a risk management firm, reminds me that choosing a provider is not simple from a risk management perspective. “The potential for cascading failures increases as cloud providers construct technologies and services on top of other cloud providers.”  In other words, if you use a service that culls demographic information for consumers in China, but you don’t realize that the service relies on Facebook APIs, then you could be inconvenienced if China decides to block Facebook.

Not every problem has a solution in the cloud.  Even if there is a viable solution for your business, there may be a fundamental hesitation.  “As the importance of a service to a business grows, there is the perception that the business is at the mercy of their provider”, Griffin Caprio – Founder & President, 1530 Technologies, Inc. What if the service goes down?  Perhaps the provider is sold to another company and the new owner starts increasing your costs.  Maybe your service provider stops supporting the service you are using for lack of customers.  Whatever the situation, you should be prepared.

So how do you avoid these pitfalls?  Planning and asking the right questions.  These are all manageable issues that are can be properly addressed when you consider each step in our Nine Steps to Cloud Nine.

Part III:  Nine Steps to Cloud Nine

The following steps should help you avoid costly mistakes as you inspect opportunities to leverage or build services in the cloud:

1.  Goals defined
2.  Roadmap
3.  IT involvement / governance / SLA
4.  Choose platform/provider

• Security (user admin access, network, storage, encryption)
• Integration (seamlessly integrated to your systems)
• Portability (migrate a virtual instance between private VPN)
• Vendor lock-in / flexibility
• Marketplace longevity/stability

5.  Lightweight prototype of a core feature
6.  Test thoroughly
7.  Measure/extrapolate against goals (Until success – repeat step 4-7)
8.  Architecture defined
9.  Build the application

The next step is the fun part- determining which strategic goals may have a solution in the cloud.  Look for future posts that discuss some example strategies in more detail.