Uptime vs. Service Improvement

The terminology might not be accurate, but let’s think of the people that process credit card transaction authorisations from retailers and check their veracity with the VISAs and MasterCards of the world as Financial Service Providers (FSPs).

The basics of this authorisation process work as follows: The Point-of-Sale (PoS) device or commercial website take an end-user’s details and, in some cases using the backend messaging protocol standard ISO8583, request the transaction be authorised. This request goes to the FSP, which in turn – always using the ISO8583 standard – validates the authorisation request with the credit card provider. The FSP isn’t merely a conduit, either – they actually hold business bank accounts that funds are paid into.

 

PoS devices and commercial website authorisation requests clock up at alarmingly high levels. This webpage says that there were, in 2009, c.50 million dial-up PoS transactions PER DAY in the US.

 

For the FSP, then, Quality of Service (QoS) is kind of an important issue. Downtime, dropping transactions, service outages and the like represent really bad news.

 

Which leaves them with a couple of issues when it comes to launching new services, maintenance, upgrades – all things that in themselves are unavoidable for organisations selling infrastructure services.

 

Launching a new service, for instance, might imply all hands on deck as the new service is cut in, just in case the worst happens. This is a scary situation. ‘Call us if it doesn’t work’ is not an acceptable customer relationship stance in the retail environment.

 

The alternative, of course, is to manually craft traffic, but this is still lab testing without real world exposure, which means the situation above still applies at some point.

 

A better option is to clone traffic and do testing in a way that doesn’t threaten QoS. The BIG-IP TMOS platform makes this possible because it’s a full proxy. It copies traffic, forks it off to the test lab and receives, reads and interprets the message so live testing can happen without risk.

 

To understand the importance of this, think about it in terms of how much money is being made by the FSP.

 

Another issue arises when authorisation requests come in. The requests are generally machine-gunned, without intelligence, to a random UNIX server. This ignores the fact that some transactions are more important than others and, in turn, means QoS isn’t being applied to these requests.

 

Just as in the first example, a full proxy platform allows interception, interpretation and intelligent routing of message types, which number in the hundreds. On top of being able to treat some message types differently for commercial reasons, this also allows fault finding and diagnosis. Transactions can be isolated and examined on a per-customer basis, which means you can diagnose faults per customer and therefore apply better QoS.

 

A final point to demonstrate the useful application of full proxy architecture for FSPs: Say there’s an intermittent authorisation problem, and you have a suspect device in the network. TMOS means you can isolate this device, mirroring the traffic so none of it is dropped, but maintaining the flow of traffic to the suspect device until the problem is identified.

 

F5 brings resilience and agility to these situations and more in the FSP space. I’d love to hear of any practical examples you’ve come across.