Messaging In The Cloud

As Larry Ellison put it, "Software is a fashion business". Cloud computing is one of the hottest topics in the computer industry recently. As software developers that live with messaging, we would be "out of fashion" if we do not join the party in time.

With the concept of SaaS (Software As A Service) materialize, it is a natural evolution for many applications (software services) to be "hosted" in the "cloud". And also naturally, this includes the messaging services.

If you are new to the cloud computing terminology, here is a definition from wikipedia.

"Cloud computing is Internet ("cloud") based development and use of computer technology ("computing"), whereby dynamically scalable virtualised resources are provided as a service over the Internet." -- quoted from wikipedia:

http://en.wikipedia.org/wiki/Cloud_computing

In the previous article, the RESTful style of messaging had set the stage for the messaging service to be deployed in the cloud. The article titled "Meet The Web, RESTfully" discussed building a conceptual model for "messaging as a service":

(http://effectivemessaging.blogspot.com/2009/02/meet-web-restfully.html)

To enable the "messaging as a service" and deploy the service in the cloud, the (cloud) service provider would require to implement and deploy the message service in the provider's infrastructure.

Conceptually, the cloud service provider would provide the following services.

• Cloud infrastructure. This includes hardware, operating systems, and required application stacks to host services.
• Messaging service implementation. The services are available to the service consumer (authenticated and authorized) with public URIs. The service implementation may (optionally) include JMS message service as the back-end routing service.

The "cloud" concept could change the messaging development process in the corporate IT in a very fundamental way. The following issues are usually required to be included in the design and deployment for a messaging system.

• Hardware issues.
• Messaging server/service installation, configuration, upgrade, and maintenance issues.
• Cluster and Highly-availability issues.
• Scalability issues.
  

These issues are now owned by the cloud service provider if used.

IT software developers can simply use the new "web" API (such as the RESTful API mentioned in the previous article) to solve the messaging requirement between applications. The cloud service provider is responsible to have the messaging service "be available and be available all the time"!

This probably sounds too good to be true. And of course there are concerns with the new model:

• The control (ownership) of the data (messages).
• The security issues. Such as authentication, authorization, integrity, and privacy.
• Is pay-per-use model right for you?
  

The control of the data issue is usually classified as business (corporate lawyer) issues. We will leave it to be solved by the business people.

The security issues can be resolved in the current available technology. Client applications could use https, certificates, and cryptographic libraries to resolve the mentioned security issues. The cloud service provider is also likely to have a security group to address the security concerns.

Messaging in the cloud is an attractive alternative for many scenarios. Such as for some start-ups and independent developers. New applications could be developed, tested and deployed immediately without all the up front hardware and software cost.

Potential cloud service providers or current messaging providers may roll out different levels of messaging service in the near future. In the mean while, Amazon already provides the "Simple Queue Service" (Amazon SQS) that address some of the "queue" messaging requirements.

In the end, it comes to the big question. Is the pay-per-use model right for you?