One of the hidden (or certainly under-discussed) advantages of a jPOS-EE-based payment system is the time it takes to stop and re-start your application when you're cycling new features into production.
For comparison purposes: in the case of many Stratus-, Tandem- and mainframe-based payment systems, the time spent cycling the app can be huge. One of our clients requires 40 minutes simply to start the application. Factor in the stop time plus deploying the new code in the middle and it's at least an hour exercise to get your new stuff in there and working. And the operative word there is "working." If you need to do a backout....yikes! You can see these are major, major exercises requiring big two- to three-hour outage windows. They are not for the faint of heart, for sure. To heighten the stress, these big traditional OLTP mega-machines are pricey, pricey, pricey, and the cost factor + the inherent redundancy of their architectures mean that - more often than not in my experience - a production system is a single node. Meaning, when it's down, you are flat-out down. So much for your 24x7 locations. [As a former Operations Manager of a Stratus-based payment system, we would always nuance this point by including only unplanned outages in our up-time calculations.]
A jPOS-EE payment application, by comparison, can fully start - beginning to end - in well under ten seconds. The stop has similar timings. For proof of that, you can look at this start sequence taken from an enterprise-class production system. I've done a bit of masking on client names, authorizer names and IP addresses, but the logged events and timing are as I pulled them off the raw logs produced by our jPOS-EE production application. You can see that from start to finish, it's about a four-second exercise.
This 'new reality' - when combined with the fact that jPOS-EE can be deployed on low-cost servers in a multi-node scenario - gives you (and your client if you're consulting) incredible degrees of flexibility and freedom. For example, this past weekend we had an emergency change that needed to go into place at a client site. We needed to get the change validated through production Debit traffic. Given that Debit there is currently in 'beta' mode at a couple of non-24-hour locations, that meant a Saturday working hours install. While multiple nodes and a Cisco load-balancer were surely helpful, what makes an exercise like that even within the realm of comprehension are the dramatic differences in start/stop metrics that jPOS-EE brings to the table vs. its predecessors.
Recent Comments