Many customers have now used SOA best practices to rebuild their infrastructure. But, it's surprising how many of the customers are leaving a lot of potential savings on the table. A SOA style architecture with an ESB provides a great infrastructure to quickly achieve sizable savings and further demonstrate the value of SOA to the business.
I think a lot of customers think of extreme performance when they think about products like IBM WebSphere eXtreme Scale. Millions of transactions per second. Hundreds of servers and so on. "We're not facebook or google, we don't need this". They may wrongly conclude it's not for them. But, the reality is there are very few customers with those kinds of requirements. However, there are many, many more customers with conventional type applications doing a couple of hundred transactions/sec or less who could readily use WebSphere eXtreme Scale to save them a lot of money for little investment especially when they have already made the investment to go SOA.
WebSphere eXtreme Scale can be readily used as a very advanced caching technology with immense capacity and very low response times. We regularly talk with customers who back ends systems are under pressure. These backend systems range from simple databases, to SAP systems, mainframes running DB/390, CICS, IMS or other valuable enterprise applications. Todays economic climate means belts are tightening so there is little money available to expand the capacity of these backend systems even as additional load is known to be coming.
At the same time even if business is flat, budget controls are at best flat. Many customers report having to run with flat or smaller budgets for backend systems even while adding more demands on them in the form of additional applications leveraging the backend systems.
Most customers estimate that there are many redundant requests being handled by backend systems. One customer with an ESB fronted mainframe estimated 25% of all service requests are duplicates of requests issued within 24 hours, another indicated 50%. Some use cases are as high as 80%. Adding a large cache to such as ESB can capitalize on this and effectively reduce the load on those backend systems by that amount. This results in better response times and cost savings in terms of load on the backend systems. This means your backend can handle 25% more load without a capacity increase.
An ESB cache is an extremely cost effective way to introduce WebSphere eXtreme Scale in to an organization. Add a mediation to the ESB. It doesn't change the front end applications invoking services on the bus NOR does it change the backend system. It just means adding a 'mediation' to the ESB which checks the cache first before hitting the backend. WebSphere eXtreme Scale can handle evicting the data.
Could you do this with a normal, non distributed cache? I don't think so. That 25% saving takes 24 hours of caching to do. That can be a lot of data, more than will fit in a single JVM. You also need a shared cache so that no matter which server received the initial service request, ALL the servers benefit from the cache as soon as a single server caches something. This is crucial to getting the most out of this pattern. A conventional in process cache CANNOT do this. You need a network attached distributed cache. WebSphere eXtreme Scale makes 10GB, 100Gb or even Tb caches possible with very little work. This kind of use case is usually very straightforward to implement and can usually be readily integrated in to a SOA application.
So, what are you waiting for? You had the foresight to envision a SOA architecture and you invested the money to deploy it, exposing backends as services, deploying an ESB and so on. Make sure you get the most out of that investment and deploy WebSphere eXtreme Scale to get you that kind of saving too. This is low hanging fruit. We had a recent customer achieve 500K USD a MONTH in savings after deploying IBM WebSphere eXtreme Scale to take load of a mainframe.
Comments