Cloud Computing – ESB as a Service

Enterprise Service Bus (ESB) has been at the fore front of SOA uptake. There were times in the recent past, where the mere use of an ESB was thought to be the indication of SOA adaption.

For message mediation, application of quality of service (QoS) characteristics, logging and auditing, message transformations and many other enterprise application design patterns, ESB is the natural choice. 

However, very few has ever thought about ESB to be something that can also be made available on the cloud as a service. What does it mean for an ESB to be on the cloud as a service?

Well, there is a practical answer for this, you can have a look at StratosLive ESB as a service.

Let me explain a bit more what the ESB as a service is all about. It is the same phenomena as an ESB, except the fact that, now you can just subscribe to it, like you would do for GMail, or an Amazon cloud service. You have zero setup, admin and management cost, you have an ESB, multi tenanted and that act the same way that a traditional ESB could do.

Why would one use an ESB on the cloud:

  1. Use it as a playground to try and test the applications
  2. Get your POCs and trail applications up and running and proven with minimal time and minimal cost
  3. Make it the public gateway, though which your partners, suppliers and clients could consume your services
  4. Integrate applications deployed on-premise and/or on private cloud with public gateway with ease
  5. Scale up excessive message mediation load onto public cloud, with the same ESB artifacts deployed on premise or on private cloud

Some applications, like those online retail applications, require to meet strict response times to ensure better user experience. Hence, those apps will have a cluster of ESBs deployed to meet performance requirements. Yet, when there are abnormal peak periods, the challenge is to scale the cluster. One option is to have excessive hardware provisioned to ensure the system can handle peaks. The other option is to consider scaling up to the public cloud. And this option could save considerable amounts of money, on power, operational and admin costs.

When you want to scale up to the cloud when required, it is desirable that the same code deployed on-premise cluster doing the message mediation, can be used on the cloud. In other words, ability to go cloud should require zero code. This is one of the key features of WSO2 PaaS cloud.

ESB as a Service

And for new applications, new integrations, or for the next iteration of your SOA project, you do not need to download, install and configure an ESB – though it is not much of a hassle with WSO2 ESB to do those. May be the other ESB that you used to work with, took it days to figure everything out – good news – try the ESB as a service today and experience the ease of use. And your sample or POC could run in minutes, then deploy those same artifacts on the downloaded WSO2 ESB.

Note that WSO2 have had ESB as a service from November 2010, and we are continuously improving the service. If not the only one, WSO2 ESB is by far the most open and most mature ESB as a service available as of today. You do not need to take my word or anyone else’s word on this, as you can try it for free, today.

Technorati Tags: ,,

Comments

Anonymous said…
I'm interested in hearing your thoughts on my analysis that demonstrates how multi-tenant, shared container clouds lowers cost of ownership compared to dedicated resource, single tenant dedicated container clouds.

The analysis illustrates how deploying middleware as a service (e.g. ESB-as-a-Service, registry-as-a-service, identity-as-a-service) reduces operational management effort, lowers infrastructure spend, and decreases software license (or subscription) cost by a significant amount.

The fully white paper can be read at http://wso2.com/whitepapers/cloud-native-advantage-multi-tenant-shared-container-paas/