Guidelines to Cloudify

#Loose coupling mantra

When designing an application for cloud, consider design with decoupled components. This can be ensured by minimizing the assumptions that one component makes about another while exchanging message from one to another. Since components are loose they concentrate more on individual features, these components can be tied together using a reliable & highly available infrastructure viz. message oriented middleware or datastore.

#Chatter will shatter

Network in cloud is unreliable when compared to one in hosted environment. Chatty APIs works well in LAN but fall upside down in cloud environment. Relying on chatty protocol can dramatically drop in performance of application. Below are a few important consideration to get this minimized:

1. Minimize round trips: Closely inspect application APIs to identify if calls can be clubbed together in one. Instead of designing fine grain APIs rely on coarse grain ones, these can be practices by including aggregates over entities as return parameter in interface definition of endpoints.
2. Service oriented design: Another reason why protocols become chatty, programmers thinks exposed APIs in terms of fine-grained distributed objects rather coarser-grained services.
3. Design Async-Ackless APIs
4. Consider thick client based design to hand off responsibility on clients.

#Graceful degradation

"Everything fails all the time" keep this phrase behind the mind while thinking of designing application for cloud. Avoid SPOF (single point of failure) is the key to achieve this, while designing consider assume nothing and consider failures as 'first class citizen' of the service. Failures in the system generally cascades and there by has an effect on all the components of the application.

#Statelessness with REST

In an application with each component running on different compute node, the chance of occurrence of failure increases when they are deployed on cloud, reason being cloud nodes have an inherent behavior of a low availability. Also, to meet the demand there are needs for horizontal scaling in and out. Thereby component has to be designed in a way that they do not contain any internal state, but completely rely on external persistent storage. Since the component instances do not have an internal state, no data is lost if an instance fails. Such a setup also significantly increases the capability of the componentized application to scale-out, because multiple components can share a common data store and thus act as if they all had the same common internal state. Adding and removal of components, part of scaling operations, is also simplified. However, the scalability of the central data store becomes the major challenge when using stateless components.
REST based architecture is an absolute fit per above discussion. REST consider transmitting the state each time component is accessed.