Pick Your Cloud Model

Cloud computing is a category your application is either a part of, or it isn't. We might even go so far as to call it a paradigm, a way to classify software – your code is either object-oriented or something else, like a functional paradigm. As a model of computing, cloud means a lot of things, its too broad to describe anything particular. Does your car fall into the category of “vehicle”? Yes, but that doesn't tell us much about the car. You can't exactly tell someone you travel by means of “vehicle” without getting a laugh or two. You can, however, say something like “I drive a four-wheel drive truck”. This is something the other party can relate to, sparing the technical jargon. Perhaps there isn't any further-refined sub-genres of the cloud just yet. Maybe a good starting point is looking at what we're hoping to accomplish with our software. Maybe then we can better identify auxiliary cloud models, and when it makes sense to use one over the other.

The term cloud computing is notoriously ambiguous. With good reason too, I don't think there is an easy way to define it as it means different things to different people. Software systems that utilize cloud technology have their own vision of what the cloud is exactly. Rather than trying to define an all-encompassing definition of what cloud means, perhaps the better approach is to identify some of its well-defined components and try to piece them together as something that is a “kind of” cloud. Why do we need to stuff everything we do over the Internet into a single pigeonhole? I say leave it vague – the cloud means events that take place over network-connected nodes. Let's focus the more tangible models of cloud computing.

The cloud's most compelling pronouncement is budgetary - saving money. We can use cloud provider's resources for less than it would cost us to buy, setup, and maintain our own. There are other, technological benefits to cloud computing too. Providers give us APIs we use to store and retrieve our data, to control our virtual machines, or to let someone else do it for us. How does this technology coalesce with your business goals? Do cloud offerings somehow solve deficiencies in your software?

One universal problem throughout all information technology is lack of physical hardware resources. The goal of any business is to scale up their operations, meaning that they have a large demand for whatever it is their software does. Say you're operating an online store and you've got a lot of customers. The software you started with isn't going to fulfil the demand of your newly acquired customer base. You've now got a scaling problem, which is in the most optimistic sense, a good problem to have. The need to scale up equals lack of compute resources – CPU time, memory, storage, and bandwidth.

The virtual cloud model can help with provisioning more physical hardware resources as they're needed. With this model, you deploy your existing application, without modification, to a cloud provider. The is no need to hack your software for the sake of potability. As long as you can get it running as a virtual machine you can deploy it to the cloud. When your software is virtual, its no longer at the mercy of the hardware. When your hardware fails, always a safe assumption that it will, you've got other copies of your application – new copies can be cloned as required. Of course, I'm over-generalizing a little when I say you deploy to using the virtual model with no modification. There is no such thing as software that knows how to adapt to a new environment and perform optimally without error.

Having said that, as a consequence of virtual machines being so easy to deploy, so readily available, so cheap - they're replaceable components in this model. You can find yourself a virtual machine that plugs into your infrastructure. This is probably something specialized, something that serves a particular purpose, like a database server or a cache node. The virtual cloud model promotes reuse and interchangeability.

Whats different about the virtual cloud cloud model from anything we've done in the past is running your entire infrastructure on a service provider's hardware. Not just a few services, but the whole thing. This can significantly lower your operating expenses, absolutely. If you don't have any hardware to operate, you've essentially eliminated that cost. The virtual model of cloud computing isn't for everyone, because not everyone is capable of migrating their existing software to an entirely new platform. Even armed with the know-how, would you really want to do it? In addition to the risk of carrying out such an endeavor, you've still got to go through the process of migration, even though you don't need to write new code.

The alternative cloud model, as I see it, is that of the service model, the service-oriented architecture if you will. The service model is fine grained while the virtual model is coarse grained. Services offer small bits and pieces of data and functionality where the fundamental unit of a virtual environment is that of an operating system.

There are all kinds of services available on the web. The web itself, that is, individual web sites offering content are a prime example of a service. If you subscribe to the opinion that the cloud is nothing more than an acronym for the Internet, you're probably a service-minded person already. The service approach solves the same basic problems as the virtual approach – finding ways to cut computing costs and provisioning more resources at a moments notice. Instead of offering virtual machines, the provider offers a service, another type of resource analogous to a virtual machine.

Storage is the most common service you'll find on cloud providers. Your application makes an API call to store a chunk of data. It makes another call to retrieve that chunk later on. An interesting usage scenario is using cloud storage APIs as your secondary storage, as a replicated copy of your primary data hosted elsewhere. The service cloud model isn't just about storage, its about providing an API for anything, any computation that you don't want to perform locally. Maybe you can't perform it locally because you cannot keep up with the demand. Or maybe you simply do not have the required software to do it. Imagine a charting API that produces chart images based on supplied input parameters. The Google chart API does just that. All the client cares about is producing the necessary input data for the chart. Generating the chart image is up to the API, my input parameters processed somewhere in the cloud.

What are the differences between the two cloud models? How do I know which one to use? Do the two models have anything in common with one another? The key difference between a virtual cloud model and a service cloud model is the application it self. Take a photo printing store, for instance. This store allows users to upload their digital photos to be printed and mailed to the customer. This business's website needs several different components to operate. It needs the website itself, this includes things like the user interface, static pages that display information about the company, the services offered, and so on. The facility to upload photos is component on its own, the service for processing payments is also a separate component, along with the facility to queue the physical photos for printing.

Let's now imagine we're going to deploy our photo store using the virtual cloud model. Each component, the website, the upload facility, the payment gateway, and the print queue, they're all virtual machines. Each component of our photo printing system is an operating system that can run in any virtual environment. If one goes down, it can be replaced with another copy of that same component. In our own local environment, we create the photo print queue and test it. This same utility gets deployed, without modification to the cloud service provider. However, deploying without modification is a little misleading. Our components still need to orchestrate with one another, not a trivial task unless I've found some system to facilitate the communication amongst the different photo printing components. Unlikely given that this is what makes our service unique and thus competitive. I've got to write something that does this.

The alternative method is to employ the cloud service model approach. Rather than deploy each of our application's components as a virtual machine, we deploy the photo printing website on our own host, calling different service APIs from the cloud to help our application along. Maybe we call a storage API to save uploaded photo files. Maybe there is a cloud API we can use use to queue the photo print jobs, a message queue perhaps. There are a ton of payment gateway APIs that we can use.

So which model is better? There isn't a definitive measure of value when comparing the two models with one another. Not without a context. The question instead, should be something like, which model is better suited for what I'm trying to achieve? How does cloud technology help me when my own resources are running dry? You have to ask yourself, how equipped am I to operate a virtual model and is it really just a matter of deploying my software without modification? Or is there a lot of mediation code I'm going to need. Maybe something like this already exists, how much will it cost?

If the virtual model doesn't help you, if you're not technically capable of operating such a setup, or maybe its just not cost-effective, you can look at the service cloud model. The service cloud is all about providing APIs to applications, APIs that offer something of value to the application. Another factor favouring the service cloud model is deployment and availability. If my software utilizes one or more cloud APIs, they must have already existed before my application decided to use them. That is, after all, the value proposition of the provider offering the API. Consequently, APIs should always be available because this is the reason for the provider's existence, to offer applications such as ours, compute resources on demand.

The cloud service model might also be lacking depending on what you're trying to build. Consider our photo printing store. We've got some fairly well defined components that will help it match the customer demand. We've come to the conclusion, during the design of our system, that we need APIs that do certain things. Odds are we'll be able to find a payment gateway that will suit our application's needs just fine. But what about the printing queue component, the one where we send photos to be printed? This is a requirement specific to what we're trying to do with our own service. So we're going to have to build our own service to do something like this.

Can the two cloud models conspire to offer real value? My thoughts are, one can serve as an adherent to the other. Take our photo printing pursuit for example. We've examined what it would be like running in the cloud as both a virtual cloud model and as a service cloud model. Both have their advantages – the virtual model is gives a clear distinction between components and total control as they're created by us. We can also find virtual components off the self that do what we want. The service model is lightweight, as in, we don't have to deploy changes to it because they're hosted by the cloud. We can design our applications with these cloud service APIs in mind, giving use fine-grained control over how our software interacts with the cloud.

The two models can certainly help one another out. A solution for our printing service job queue component might be to implement our own virtual service. That is, a combination of a service and virtual model where a virtual machine, implementing the job queue service we're looking for gets deployed and we have total control over it. We're taking advantage of the control and flexibility of deploying virtual while keeping the design philosophy of our application's features and using an API, service driven approach to doing certain tasks.

In the end, there are probably several more of these sub-genres of cloud, we can concoct and describe once we've encountered real problems and devised real solutions to them. We simply use the higher-level, vague cloud term for inspiration.