During a move to cloud computing, people talk about porting applications to cloud computing providers such as Microsoft and GoGrid. They even build new applications in the clouds on platforms such as Google App Engine and Engine Yard, but they've yet to focus on good application design for use on cloud computing platforms. Perhaps it's time we all put some thought into this.
Thought leadership around application design/architecture for cloud computing typically centers on a particular cloud provider. While that's certainly important, there should be some provider-neutral general application design guidelines. Also, I assert that most of the best practices for designing and creating applications for cloud computing platforms are consistent with, well, good application design practices in general -- in other words, nothing radically different, even though it feels like it should be.
[ Get the no-nonsense explanations and advice you need to take real advantage of cloud computing in the InfoWorld editors' 21-page Cloud Computing Deep Dive PDF special report, featuring an exclusive excerpt from David Linthicum's new book on cloud architecture. | Stay up on the cloud with InfoWorld's Cloud Computing Report newsletter. ]
That said, here are some general guidelines to consider, removing security and governance for now:
Leverage a three-tiered architecture when possible. One of the advantages of cloud computing is that you can place specific application components -- typically the database, application processing, and user interface processing -- on separate providers or, perhaps, a mixture of on-premise and cloud computing-delivered systems. This is possible because each tier is functionally independent from the other. Thus, you can build your user interface using Java within an on-premise system, which talks to an application server on your cloud infrastructure provider -- say, 3Tera -- which in turn talks to a database service on another provider (for example, Amazon.com's new RDS).
If you're thinking about having all three tiers reside on the same platform for simplicity, reliability, and performance, that's fine. However, using this type of architecture will provide you with options down the road, and you may want to mix and match platforms (cloud computing and on-premise) for each tier to maximize performance and minimize costs. In other words, you're designing for architectural agility.
Leverage a loosely coupled architecture. Extending my suggestion that you use a three-tiered architecture and driving toward the use of SOA, you should make sure that all application components are loosely coupled or, at least, minimize as much of the dependencies as possible. Again, this approach moves toward architectural agility that provides us with additional platform options, now and in the future, cloud computing and on-premise.
Consider the chatter. Distributed applications need to communicate between application components (such as database, application processor, process engine, and user interface), and while it's easy to work around a "chatty" application when on the same cloud computing or on-premise platform, chatter can cause latency with distributed application components. Make sure to structure your interapplication component communications to be as efficient as possible, perhaps using asynchronous communications (messaging) where applicable.
Avoid proprietary features. While your cloud computing provider's native APIs may have some nice features to make your application shine, you're trading off portability. Thus, while some use of native APIs is unavoidable, you should design your application with portability in mind. Keep an eye on the emerging standards around application portability for cloud computing, but don't factor in standards or factor out architecture.
Common sense? Old-school application architecture? Sure. However, as you build more applications for use in the emerging world of cloud computing, the applications that are designed well for use either on cloud computing or on-premise platforms will provide the most value throughout their lifecycle.