Cloud Services - Design Considerations

We all realize that SOA and Cloud computing go hand in hand and are complementary in nature. After all we talk, about everything as a service (XaaS) in the Cloud world. So the immediate question that comes to mind is, would the service that has been designed to be consumed in-house would serve equally well if it were hosted on the cloud? The answer apparently is "Not really". Services designed as per SOA principles (clear contract, standalone functionality) would probably be much easier to migrate to Cloud, but there certainly is a need to re-look at some of the design patterns that will be crucial in cloud orienting the services. Let's identify some of the crucial ones. 

Data Storage: Conventional services assume that transactional data would be stored typically in a normal RDBMS. However that might not be the best way moving forward to the cloud. You can sure host RDBMS on the cloud but infinite scalability becomes a problem as the data store is still centralized. Depending on your cloud platform check if it makes more sense in storing data in platform specific storage (Ex: Azure Table Storage and Amazon Elastic Block Store). 

Enhanced algorithm: (Use less compute power) This in my opinion is something which we should have been practicing all along. But we all come across smelly code and its associated in-efficiencies. That still did work in the conventional environment. But with Cloud, we pay for the compute cycles. So non-optimized code and algorithms result in direct cost to the organization. So the next time around when you see someone do a one to one string compare before sorting them or putting them in a hashtable , it would be worth taking the extra effort and time and getting it modified even if it means missed deadline. 

Messaging and Queuing: With services now being hosted on the cloud, extra care needs to be taken to ensure that the messages are not lost even if for some reason the underlying services are down. Remember, you are talking about cloud, where your capability is limited by the underlying cloud providers. Queuing provides you the additional layer of reliability where the messages are never lost and you have a robust implementation even on the cloud. 

Idempotent Capability: The same request even if sent multiple times should only be processed once. Though this is something which we have implemented in our conventional applications, the requirement is more so in a cloud transactional service. It wouldn't be a bad idea to send some unique identifiers in service headers for critical transactions to implement this capability. 

Security - Federated model: This I am sure would be faced by almost all Cloud architects. While moving services to the cloud, you would surely want to authenticate and authorize the requestor. It probably is a good idea to leverage your existing LDAP rather than creating one from scratch on the cloud. A federated LDAP (ex: ADFS) would surely help. 

Multi-tenancy: Multi-tenancy is going to be commonplace on the cloud environment especially in the SAAS world. So if you want to design services that would be used by multiple consumers in similar manner, do have multi-tenancy at the core of your design 

Integration: In all likelihood, your cloud services need to interact with your in-house services. A conventional middleware might just work but do look at the intricacies like transaction maintenance, seamless security, back-end data integration etc. Microsoft has come up with the Azure Bus specifically designed for the purpose

This gives an idea about the intricacies that one can broadly expect while moving to the cloud. 

Technology Integration Lab
Sceda Systems
www.scedasystems.com