Jun 10, 2010

Datapower – Balancing and Failover


Ok, this is a little more practical and technical than we usually get, but important nonetheless.

The IBM Datapower, as well as similar devices from Layer 7 and Cisco (and others) provide SOA security, attack prevention, and a number of ESB-like abilities (somewhat of an ESB lite).  However, these boxes tend to be EXPENSIVE, as well as having a series of add-on software modules that raise the price significantly.

The latter is a shock to many people.  One thinks of the Datapower as a physical device, like a network router.  While it is a physical device and much of it’s performance is based on optimized software placed in ASIC hardware chips, it’s also a very sophisticated software platform.  As such they’ve done the standard vendor thing of separating many of the sophisticated abilities as separate software add-on modules – adding on ability and adding on price.  For example (if I remember correctly), the ability of the Datapower to connect to a database stored procedure and expose it as a (secured) service is an add-on feature.

Because it’s an expensive device, and it’s advertised as a high availability device, and it’s considered to be a hardware platform like a router, and they want to isolate development/test from production, many organizations are taking one for development / test / QA, and one for production.  (And often none for disaster recovery!)


This is a mistake in two ways.  First, even high availability devices fail.  And if the Datapower (or other hardware based SOA security device) is layered into the security control of all SOA services, then if the device fails ALL SOAP WEB SERVICES (or at least all that go through the device for security, runtime management, and/or ESB lite abilities) are offline until the device is physically replaced.  Being it’s expensive, you can assume IBM doesn’t have them sitting around at the local office.

image Second, the device offers a multi-tenancy ability.  It has several ways to automatically separate logical instances from each other, and reasonable internal protection of one tenant impacting another.

For these reasons, it’s highly advised to cluster your Datapowers and use the multi-tenancy features to logically separate your development/test from production environments. 

And don’t forget disaster recovery!  If you are heavily reliant on this device and don’t have one in disaster recovery, then if you lose your primary data center you can be out of service for an extended time until a physical replacement can arrive and be reconfigured.  The basic rule is whatever it touches and whatever those services touch will be offline until it’s replace.  That could be a VERY big deal as integration has spread far and wide throughout the enterprise.