Cloud computing, which involves accessing applications and services on hosted servers over the Internet, certainly has become the hot tech trend for 2009. The volume of cloud applications can only be expected to grow, and this fact brings both new benefits and responsibilities for developers.
While cloud deployments can save developers from having to deal with infrastructure issues, there are some new nuances they must deal with as well. These include changes in how developers work with databases, an emphasis on stateless applications, and dealing with different frameworks.
"The big change now is that software itself is able to provision the resources that the application needs," says Lew Tucker, Sun's CTO of cloud computing. Using APIs, developers writing applications for the cloud can design them so that they request more resources from the cloud provider.
Developers need to design for redundancy and acknowledge that commodity machines are being leveraged in the cloud, says Amitabh Srivistava, Microsoft's corporate vice president for the Windows Azure cloud platform. "It's a guarantee the machines are going to fail, so you have to design your application that you're running in the cloud for redundancy," he says.
Building for the cloud requires designing stateless applications, Srivistava says. "If you have state, then that becomes a problem. The model in the cloud is if something dies, you kill it and reincarnate it" by designing stateless applications, he notes. With the cloud, "there's no concept of a local disk. There's no registry, for example. But that's all encapsulated by being a stateless app."
Sun's Tucker notes that "the easiest kind of applications are stateless. However, the interesting applications always have some kind of state, which is why we still need databases or object [stores] to store some state" for maintaining items such as user information, Tucker says. But parts of the applications that need to scale, such as the Web front end, are stateless in the cloud.
Another cloud difference: Different parts of an application might be in many places in the cloud. For example, a presentation layer might be on Facebook, storage could be on Amazon.com's S3, and application logic could run somewhere else entirely, Tucker says. "Before, people would just develop the entire app on their own servers," Tucker says.
All of these issues means that building for the cloud requires new thinking about the system architecture and an emphasis on leveraging massive scale, Tucker says. "There's no magic here. [Building scalable applications for the cloud] still requires solid engineering and design," he says.
But the cloud platforms can help. In some cases, such as with Google App Engine, scaling is automatically implemented for a restricted set of applications, while in other cases, design patterns can be used to horizontally scale applications, Tucker says. And Amazon.com Elastic Compute Cloud (EC2) provides Multiple Availability Zones, so developers can distribute an application across multiple locations. "Previously, only very large companies had the scale to do this," says spokeswoman Kay Kinton. And a capability called Elastic IP in EC2 allows for rapid remapping of an Internet address from a failed instance to a working one.
The uses of abstraction and statelessness also have database implications. For example, Azure presents developers with a different perspective on databases than the standard relational model, said Ben Day, president of Benjamin Day Consulting. The Azure storage engine does not use a standard relational database, so "a lot of the stuff you would do if you were developing a standard app using a standard relational database just doesn't make a lot of sense anymore," Days says. He cites as an example the relational database concept of stored procedures, in which query logic is close to the actual data itself. This is no longer applicable in the Azure cloud.
"The problem is with Azure is there's no guarantee that the data that you're going for lives in any particular location or datacenter or any particular device," Day says. "You end up writing basically SQL queries against the store because the stored procedures aren't relevant anymore," Day stresses. Plus, the Azure storage engine is different than the SQL Data Services cloud-based version of SQL Server planned by Microsoft, he notes, so developers need to be careful as to which they're writing for. As an example, Azure stores a 1MB file as a blob, unlike SQL Server, which stores it in a table.
It's not just Azure that has these database differences. For example, "Google App Engine abstracts away not only the actual physical hardware but any concept of a machine," says Pete Koomen, Google's App Engine product manager. That means a developer uploads code, then Google manages it and splits up the database. "Because we are automating much more of the process, there's a certain model that developers have to follow" that differs from a traditional SQL model, Koomen says.
With App Engine, developers uses Google's Big Table data store for persistent storage. "Big Table is not a SQL database, and the reason for that is because some of the functionality supported by SQL databases -- for example, joins -- make it very difficult to split a database across multiple machines," Koomen says.
"With our system, we've exposed a programming model where denormalization is encouraged from the start," with developers storing data in multiple places at the same time, he said. The benefit is that this approach lets apps run very efficient queries, Koomen says.
Koomen gives a thumbs-down on using relational databases in cloud environments: "What we found is that in very high-traffic situations, relational databases are extremely difficult to manage, and that ends up being a huge money and resource sink for developers."
Model Metrics, a consulting company, has implemented applications on Salesforce.com and other clouds. It has found that a major difference between cloud-based application development and Web and client-server development is that "things change much more rapidly in the cloud," says CTO John Barnes.
Salesforce.com, for example, offers new releases several times a year, and each upgrade might have something a developer wants to take advantage of, Barnes says. "As a developer, you need to stay abreast of those developments, keep an eye on a lot of the different blogs and also participate in Webinars," he advises.
Developers also should be aware of different design patterns such as eventual consistency, in which a change to an application might not register for a few milliseconds. "The consequence of that is that you can't utilize a database to keep track of the next value," Barnes says. "People have to program slightly differently when they're utilizing the cloud because of things like that," he adds.
But the use of loosely coupled Web services offered on the cloud makes it an easier development platform, Barnes says. Developers can focus on innovation and business logic instead of worrying about plumbing and infrastructure such as the operating system and hardware, said Barnes. The Salesforce.com Force.com cloud, for example, offers security, workflow, administration, and load-balancing.
Model Metrics had a client that originally planned to build a college admissions application on Microsoft's .Net platform but found that it was three to four times cheaper to develop on Force.com, due in great part to its use of pre-built functionality, Barnes says.
Developers, however, need to keep in mind the differences between cloud platforms and licensing models, too, Barnes says: Different clouds have different pricing schemes.
Adam Gross, Salesforce.com's vice president of developer marketing, offers a word of caution to developers pondering the cloud: Developers need to understand about the providers they are choosing. "They should develop their applications in such a way that they could be moved off that platform," Koomen says. Google enables such mobility by supporting the popular Python language and the Django Web framework, he says, and is working on open source uploading and downloading tools for moving data in and out of App Engine.