Friday, June 19, 2009

Interoperability - missing in the Cloud?

"There’s no mention of interoperability with other clouds like Google or; that will have to be left to third parties like Vordel"
From Cloud Computing Journal:

Besides security, the other big push-back against Cloud Computing is interoperability. Most organizations do not want to have to choose one Cloud Computing vendor exclusively. Certainly, in cases like the US Government (with its new emphasis on Cloud Computing) , using a provider which doesn't explicitly offer interoperability with other providers is unthinkable.

Gateways act as the pivot point between applications and Cloud-based services, as well as between the services themselves. They provide the link from local applications up to the cloud, the "on-ramp". They also mediate between different Cloud providers.

Unfortunately, when a new Cloud Platform doesn't address the interoperability issue, it is adding to the problem, not fixing it. Gateways are the answer to that particular problem.

Tuesday, June 16, 2009

Cloud Governance and Security

Today in IBM DeveloperWorks - Cloud Governance and Security

Covers applying policy to Amazon services,, client-side and "cloud-side" governance, and the role of the Gateway as a Cloud on-ramp.

Wednesday, June 10, 2009

SOA at the Federal Aviation Administration (FAA)

Government Computing News (GCN) covers this story about the selection of Vordel Gateways by the FAA, for its SWIM (System Wide Information Management) project. A lot more information on SWIM is available online (e.g. this IEEE paper). It is great to see a governement agency really using SOA to link systems together and save costs.

Tuesday, June 9, 2009

Who's been using my services? (and what response times did they experience?)

It is frightening to think about how many organizations deploy SOA (or even "just a bunch of Web Services") but have no idea about how the services are being used, who is using them, what the service uptime is, and what response times their clients are experiencing. Visibility is a big issue for SOA.

This is why we build VordelReporter. By sourcing its information from Vordel Gateways, it allows administrators to see in real-time who is using services. They can drill into individual gateways in order to see the usage and performance of services which are in that Gateway's sphere of control.

Using Gateways for SOA visibility is non-invasive, requiring no changes to the services themselves. By using the information from a product which is already deployed, the XML Gateway, it removes the danger of creating a new, standalone "SOA Governance silo".

You can do neat things like discover if a service is not performing to its SLA, and then take remedial action by offloading its XML processing on the Vordel Gateway where it benefits from XML Acceleration. Then you can see in real-time how the service response time increases. So you're actually solving a problem, using products which also perform other functions (acceleration, protocol mediation, content inspection) rather than just putting a "governance silo" in place for its own sake. With Gateways, if you discover that a service is running slowly, you an solve the problem by offloading processing onto the Gateway. With a standalone "SOA Governance silo", you can discover that a service is running slowly, but that is that.

Here's a short video showing the drill-down from a SOA topology, to a Gateway, to individual service invocations:


Paradoxically, one great feature of VordelReporter is that you don't even have to view its reports. How is that possible? The answer is that because VordelReporters real-time monitoring sources data from Vordel Gateways via a secured REST-ful pipe (here we are eating our own dogfood), can also simply send the metrics to products such as Oracle Enterprise Manager. This also helps SOA visibility, and is another example of using existing infrastructure rather than creating a "SOA Governance silo".

Tony Baer put it well back in January:
"...we also believe that the run-time governance of SOA or services cannot be divorced from the physical aspects of running IT infrastructure. Service level management of SOA services is directly impacted by how effectively IT delivers business services, which is the discipline of IT Service Management (ITSM). When there is a problem with publishing a service, it should become an incident that is managed, not within its own SOA cocoon, but as an IT service event that might involve problems with software or infrastructure."

More on VordelReporter here