Connect to the Cloud without coding

Chris Capossela on GigaOm notes some of the guidance for using Cloud Computing:

Where are the limitations and the opportunities for businesses looking to embrace the cloud for collaboration functionality? Industry analysts have been consistent in their guidance to enterprises here — look before you leap. Know what you gain and what trade-offs you might have to make — irrespective of whether your decision is to stick with on-premise, migrate completely to the cloud or adopt a hybrid model. In 2009, pragmatism will be the order of the day as enterprises strip away the hype, roll up their sleeves and get into the nitty-gritty of service-level agreements and uptime guarantees, data retention and privacy practices, support and maintenance, and customization options in order to make informed decisions about where the cloud represents the best option and where on-premise software fits the bill.
http://gigaom.com/2009/02/21/the-enterprise-the-cloud-and-5-key-drivers-for-2009/


The emerging consensus is to begin with the "hybrid model", as mentioned above. Migration completely to the Cloud seems premature, while sticking with only on-premises infrastructure ignores the benefits of Cloud computing.

But, as also mentioned above, questions of "service-level agreements and uptime guarantees, data retention and privacy practices, support and maintenance, and customization options" then come up. What if private information is amongst the data sent up to a third-party Cloud Computing provider. What if the connection to the Cloud Computing provider goes down?

Also, there is the practical question of how exactly to connect internal infrastructure to Cloud Computing. Up to now, this has involved coding (e.g. see this dev guide for the Amazon SQS Service).

Vordel has produced the Vordel XML Gateway Cloud Edition which allows for connections to Cloud Computing environments such as Amazon and Force.com without coding, and including functionality such as stripping (or selectively encrypting) private data before it goes up to the Cloud provider, response time analysis, and data transformation.

This allows the hybrid "local and Cloud" model to be deployed:



Configuration is drag-and-drop, with no coding, as shown below. All of the filters which you can see on the right of the screenshot below (encryption, monitoring, caching) are available to drag-and-drop into the circuit which runs on the Vordel Gateway:

XML Acceleration in the cloud

Software-based XML Acceleration is ideally suited to the "elastic" Amazon EC2 Cloud, since the more CPU power you add to it, the faster it goes. By contrast, ASIC-based XML Acceleration products are not "elastic", which means they are grounded, not possible to instantiate them as "instances" in the Amazon EC2 cloud. Maureen O'Gara of Sys-con covers this in the story "Not All of WebSphere Can Ascend to Amazon’s Cloud".

The many lives of Prawo Jazdy

Fresh from his escapades flouting Ireland's traffic laws, it looks like Prawo Jazdy now has a bright future ahead of him as an example of authentication gone wrong (his name is so much more plausible than "Mr X.509 Certificate").

What is the glue which bonds the Cloud with SOA?

Joe McKendrick writes about "SOA and Cloud bonding: Is this good, or too risky?". Aside from the high-level discussion, the practical question is "how exactly do you connect your SOA to the Cloud?". As Joe McKendrick rightly says, an SOA can be seen as a "private cloud". So how do you connect services from an SOA ("private cloud") up to services exposed by Google, Amazon, Force.com, or MS Azure?

One answer is to use an XML Gateway as a local "integration hub"which connects local applications up to Cloud computing based services. This can be done without coding, using the same drag-and-drop integration which is provided as standard.

That is how you practically make the connection. But what about service usage monitoring, outbound transformation, and security? The answer is that rules for caching, outage-reporting, usage monitoring, and transformation can be applied as policies (not baked into code). Perhaps more importantly, security requirements are addressed. For example, outbound data can be classified according to confidentiality (e.g. "no data which includes medical records can go up to the cloud", or "any identifying data must be selectively encrypted using XML Encryption before the data goes up to the cloud".

The XML Gateway is the glue that provides the bond between the SOA and the cloud.