Uptime vs. Service Improvement
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.