By Rich Wolski | July 16, 2010
In the last two episodes of this series, I provided commentary on four of the top five questions on "Cloud Computing" that we have heard in the Spring of 2010. In this epilogue, I reveal my presentiments related to application alterations that are requisites in cloud computing.
What will I need to do to my applications to get them to run in a cloud, private or public?
To understand how to make applications "cloud enabled" one must understand the provisioning capabilities supported by the cloud. For provisioning, a cloud-enabled application essentially has four new operations it can use to control the resources that are at its disposal: create, destroy, attach, and detach. Not all operations are supported for every resource, however. In the AWS API, for example, VMs can be created or destroyed, block-attached volumes can be created, destroyed, attached, or detached, and permanent IP addresses can be attached or detached. From an application development perspective, these capabilities are new. Thus applications must be augmented or enhanced to be able to take the best possible advantage of them. Moreover, some of them seem similar to existing programming abstractions making it tempting to try and simply replace the old versions with the new ones they resemble. For example, one common misconception is that VM creation in a cloud is equivalent to process creation on a server. Both encapsulate a memory address space and give it one or more CPUs. A VM, however, carries one or more file systems, configuration information that describes how it should behave, and an operating system kernel that defines what it can do when it is instantiated. These additional features are typically part of a server processes so a simple one-to-one translation of server processes to VMs doesn't necessarily yield a working application. The same is true for the other cloud abstractions. While many of the operations are similar to more familiar programming constructs, some care is required to ensure that applications use the new abstractions correctly.
In a similar vein, applications must be able to use the cloud storage model or models effectively to be able to take best advantage of the cloud. The key characteristic of cloud storage is that it is built for scale. While such a characterization certainly sounds appealing, it has (in the view of some) profound effects on how storage behaves when it is used. For example, most cloud storage hierarchies contain PUT/GET bucket storage (also called "blob storage" somewhat unceremoniously). In it, buckets (named storage containers) and created or destroyed and objects (named subregions of a container) are either retrieved or stored. The storing of an object, however, does not overwrite an existing copy necessitating some form of version number. It is up to the application to manage the creation and deletion of buckets and the versions of objects explicitly. While this storage model appears overly complex when compared to typical file system semantics, the advantage is that it can be made to scale to a far greater extent with substantially less mechanism in the software implementing it.
Summarizing, developing applications for, and porting applications to the cloud involve making use of the provisioning operations and the cloud storage model or storage models. Often these features can be incorporated incrementally in a porting effort but they, collectively, deliver the power of cloud computing to the application.